Re: [casper] "No Blocks" in CASPER DSP blockset

[G Jones]

Hi Jason,
I distinctly remember this problem but couldn't remember the solution.
Digging through old emails I came across this from the esteemed Mark
Wagner, hopefully it helps!

"In case someone else runs into this... I just had this issue that after
'loading' all the blocksets into Simulink and selecting them in the
browser, it only showed 'No Blocks'.  I'm not sure of the cause, but it
turns out I simply needed to change the permissions on /tmp/LibraryBrowser
to a+rwx.  "

Take care,
Glenn



On Thu, Sep 14, 2023, 06:02 Jason Ray  wrote:

> Hi All,
>
> I have a question about our simulink libraries at GBO.  The backstory is
> that we installed a version (casper_astro_soak_test for Xilinx 14.7) of
> the casper tools many years ago during VEGAS development.  It has always
> worked fine until sometime in the past year or so, I can't seem to load
> the CASPER DSP blockset library.
>
> When I launch the simulink library browser, all of the libraries
> populate correctly except for CASPER DSP blockset.  When I click it, a
> window pops up "generating repository for CASPER DSP blockset" for about
> 10 seconds, then it closes and the browser says "No Blocks".
>
> I can right-click on CASPER DSP blockset on the left pane of the library
> browser and open the library and all of the blocks are present and
> accounted for in the model file.  It seems that I can drag blocks out of
> the library model file into a new model without issue.
>
> I can rebuild old designs that contain CASPER DSP blocks without error,
> I just can't see them in the library browser.
>
> As far as I know, nothing has changed with respect to the CASPER
> installation, the computer it runs on, etc.
>
> Any idea why they don't show up in the browser?  We've confirmed the
> correct permissions in /tmp/LibraryBrowser area (based on the Mathworks
> bug report 673978), and even clearing out that area, but that didn't help.
>
> Thanks in advance!
> Jason
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/58fc0fae-80df-43be-b166-1554ac5647c9%40nrao.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/CAGK_ABf9HMX44_224%2BjB7KgbsBBPqTMQ7K1%2BRvvQV4jqsS64rA%40mail.gmail.com.

[casper] Embedded software position

[G Jones]

Hi CASPER friends,
I wanted to bring this job posting for an Embedded Software engineer
 at the
quantum computing company I'm working at now, Rigetti Computing. The
technology we use has a lot of overlap with radio astronomy (microwave
signals, cryogenics, real-time DSP), so I thought this might be of
particular interest to the CASPER community.

Please let me know if you are interested. I am happy to tell you more about
the position and the company.

Thanks,
Glenn

-- 
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] Netboot for ROACH2 in 2017

[G Jones]

Hi Adam,
When I needed to update tcpborphserver I just cloned the code for it from
the repo (I think it was in the katcp codebase) and compiled it on the
Roach. I think I had to remount the filesystem to make it writable but
otherwise I remember it being fairly straightforward.
Hope this helps,
Glenn

On Jul 7, 2017 8:57 AM, "Schoenwald, Adam J. (GSFC-5640)" <
adam.schoenw...@nasa.gov> wrote:

> Hi All,
>
>
>
> The point:
>
>
>
> I’m looking for a new snapshot, or instructions on how to make one, for
> netbooting a roach2. Can anyone either update the git, namely the snapshot
> file,  at https://github.com/ska-sa/roach2_nfs_uboot or give instructions
> on how to properly merge recent changes into the nfs file system?
>
>
>
>
>
> Details:
>
> I got a netboot server up and running on Ubuntu 16.04 last week.
>
> I followed a combination of instructions from https://casper.berkeley.edu/
> wiki/Getting_Started_with_ROACH2 and https://github.com/ska-sa/
> roach2_nfs_uboot
>
>
>
> I extracted the “roach2-debian-fs-snapshot-24-10-2012.tar.gz” snapshot
> and made a symlink from ‘current’.
>
> When net booting, the ROACH2 followed the symlink in
> “roach2_nfs_uboot/current/usr/local/sbin/ tcpborphserver3”.
>
>
>
> This tcpborphserver3 was fairly out of date(2012 I believe, like the
> snapshot), and I was having errors controlling my firmware through python.
>
> I tried extracting the tcpborphserver3 from 
> roach2-root-phyprog-release-2015-04-01.romfs,
> placing it with a new name into ‘roach2_nfs_uboot/current/usr/local/sbin’
> and linking to it. My primary complaint here was tcpborphserver3 stopped
> flashing gzip files. I also wanted .fpg functionality from the newer ska-sa
> mlib_devel.
>
>
>
> After my trials and errors with netboot, I decided to flash the kernel and
> romfs (I was too nervous to flash uboot) after reading this
> http://www.mail-archive.com/casper@lists.berkeley.edu/msg06347.html , and
> I am now running in soloboot.
>
>
>
> Thanks,
>
> --Adam
>
>
>
> 
>
> Adam Schoenwald - Electrical Engineer
>
> Code 564/Instrument Electronics Development Branch
>
> NASA Goddard Space Flight Center, Building 11, E227
>
> Office: 301.286.4175 <(301)%20286-4175>  | Cell & Text: 631-241-0003
> <(631)%20241-0003>
>
> 
>
>
>
> --
> 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] ROACH2 won't power on

[G Jones]

Hi,
To follow up on this, I confirmed that the power supply had indeed failed.
The fan was completely seized up. I also checked C163 out of an abundance
of caution (thanks, Jason, for the notes!) and it seemed fine. Replacing
the power supply brought he ROACH2 back to life.

Thanks,
Glenn

On Mon, May 8, 2017 at 8:33 AM, Jason Ray <j...@nrao.edu> wrote:

> Hi Glenn,
>
> A while back, I repaired a roach2 problem that had similar symptoms.  Its
> probably not terribly likely that yours has the same problem, but I thought
> I'd share in case...
>
> The short story is that a capacitor (C163) failed and I could measure
> ~220ohms across it.  This particular cap is part of the soft reset
> circuitry associated with switch S1, and was pulling down the signal,
> holding the roach2 in reset.
>
> I removed that capacitor and saw pretty major evidence of re-work in that
> area (missing pads & traces, small wires from nearby vias, etc).  We never
> use the soft reset switch on the board, so I just removed all of those
> parts and the roach2 board now functions as it should.
>
> Good luck!
> Jason
>
>
>
>
> On 5/5/2017 4:45 PM, G Jones wrote:
>
> Hi,
> Our ROACH2 suddenly failed recently. The symptom is that it won't power
> on. The green AUX power LED is on and the red FAULT LED is on. Pressing the
> power button and the reset button does nothing.
>
> Looking back at the archives, I see that the standard ROACH2 power supply
> is known to fail after overheating. Is this a symptom of that failure? I
> will try another power supply shortly, but I'm curious if others have seen
> this symptom before.
>
> Thanks,
> Glenn
> --
> You received this message because you are subscribed to the Google Groups
> "casper@lists.berkeley.edu" <casper@lists.berkeley.edu> group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

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

[casper] ROACH2 won't power on

[G Jones]

Hi,
Our ROACH2 suddenly failed recently. The symptom is that it won't power on.
The green AUX power LED is on and the red FAULT LED is on. Pressing the
power button and the reset button does nothing.

Looking back at the archives, I see that the standard ROACH2 power supply
is known to fail after overheating. Is this a symptom of that failure? I
will try another power supply shortly, but I'm curious if others have seen
this symptom before.

Thanks,
Glenn

-- 
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] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

The broken connections between blocks are causing your problem. Often that
happens when the ports on a block change between versions. You will likely
have to figure out how to connect them back up (perhaps by looking at how
they're connected before you run the casper_update_blocks script. Not sure
exactly why they're breaking in your case, but I'd suggest trying to follow
exactly what Jack did (i.e. using exactly the same model etc.)

Glenn

On Fri, Nov 18, 2016 at 1:05 PM, A. T. Josaitis  wrote:

> Dear Jack (and the rest of the Casper family),
>
> I just wanted to follow-up with my last message, and see if anyone had
> recommendations for how to correct the shared BRAM errors I'm receiving in
> tutorial 4 (see last message in this thread). The blocks are updated, and
> I've also tried replacing them by hand with the correct blocks in the
> library. Neither updating nor replacing the blocks solves the errors. Other
> thoughts?
>
> Best,
> Alec
>
> On Nov 16, 2016, at 2:41 PM, Alec Josaitis  wrote:
>
> Dear Jack,
>
> So, first of all, my apologies for giving you the wrong file: I was
> actually using poco_wide_r316_new.mdl, because the github says that newer
> file was specificially intended to be used with MATLAB 2012b. You are
> right, poco_wide_12_r316.mdl does not have the black box. However, when I
> update the block diagram for this model, I receive many errors related to
> the shared_bram block; I've attached the error log below. Did you receive
> these errors when you updated your block diagram? I assume not because I
> tried compiling the design via casper_xps and quickly received an error.
>
> I've included a screenshot of the first error, "Error 0001: Undriven input
> port Block: 'poco_wide_12_r316/dir_x0/aa/Shared BRAM/convert_din1'". I
> think this convert_din1 error occured in every instance of the shared BRAM
> blocks in dir_x0 and dir_x1, and you will notice in the screenshot that the
> error appears because of a disconnection between munge_in and convert_din1.
> Should those blocks really be disconnected? Do you know why they came
> disconnected in model?
>
> Best,
> Alec
>
> On Mon, Nov 14, 2016 at 10:29 PM, Jack Hickish 
> wrote:
>
>> Hi Alec,
>>
>>
>> So I have MATLAB 2012b, Xilinx 14.7, and mlib_devel commit 4c7ba5efb4.
>>
>> I cloned the tutorials from github.com/casper-astro/tutorials_devel.git,
>> and unzipped poco_wide_12_r316.mdl.gz. This model doesn't seem to have any
>> black boxes in it. I ran update_casper_blocks(bdroot) and some 115 blocks
>> are found and updated. After that a block diagram update completes OK, with
>> a few warnings. I'm currently compiling the design via the casper_xps gui,
>> and so far nothing seems amiss.
>>
>> Cheers
>> Jack
>>
>> On Mon, 14 Nov 2016 at 17:43 Alec Josaitis  wrote:
>>
>>> Dear Jack,
>>>
>>> Yup, I was working with  poco_wide_12_r316.mdl. The only substantive
>>> change I can recall is replacing the Xilinx Black Box version of the 
>>> pfb_fir_generic
>>> to the one in the DSP blockset, programmed as specified in the tutorial
>>> .
>>> (because, a fellow Casperite thought the reason I was facing previous XSG
>>> config errors was due to this black box).
>>>
>>>
>>> Thanks for the help with recreating this problem! For reference, I'm
>>> using the mlib_devel git commit 4c7ba5efb4
>>> 
>>> .
>>>
>>>
>>> Best,
>>> Alec
>>>
>>> On Mon, Nov 14, 2016 at 7:52 PM, Jack Hickish 
>>> wrote:
>>>
>>> Hi Alec,
>>>
>>> That's a fun one. Is this the vanilla tut4 design after running
>>> update_casper_blocks? I can try and recreate the problem here
>>>
>>> Cheers
>>> Jack
>>>
>>> On Mon, 14 Nov 2016 at 16:35 Alec Josaitis  wrote:
>>>
>>> Dear Dave and Glenn,
>>>
>>> You were both correct, my MLIB_DEVEL_PATH returned any empty string; the
>>> variable was never set. I'm amazed I got to tutorial 4 without that mistake
>>> making itself present! I am now able to implement the green blocks as
>>> expected, and when I run the Simulation -> Update Diagram command, I do not
>>> receive any errors in a .log file. Indeed no error.log is even generated
>>> (as they had previously). However, I am still unable to compile the .slx
>>> file because of the following error:
>>>
>>> Operands to the || and && operators must be convertible to logical
>>> scalar values.
>>>
>>>
>>>
>>> I've checked the Casper Archive and noticed someone else having a
>>> similar problem
>>> ,
>>> but there wasn't a clear resolution and I'm not quite sure how to fix this. 
>>> This
>>> link
>>> 
>>> provides the warning statements 

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

You don't need to run the *_init.m files yourself, matlab does that for you.

Click the  "set path" button in matlab and make sure you see the directory
that will be something like .../mlib_devel/casper_library

I suspect that you don't have your startsg.local or startup.m

at the matlab prompt, what does
getenv('MLIB_DEVEL_PATH')
return?

It should point at your mlib_devel directory.

Glenn

On Thu, Nov 10, 2016 at 4:56 PM, Alec Josaitis <josai...@umich.edu> wrote:

> Dear Glenn,
>
> In trying to get to the root of this issue, I've started digging through
> the Casper Library files. In what seems to be the principle .mdl file,
> "casper_library.mdl", I notice that the first actions done are to load
> other .mdl files, such as "casper_library_ffts.mdl", and
> "casper_library_pfbs.mdl", and I assume that inside that inside these .mdl
> files are where the respective library blocks are instantiated. Inside the
> casper_library folder of my mlib_devel, I do indeed see the .dl files
> labelled ""casper_library_ffts". "casper_library_pfbs", etc. However, I do
> NOT see one labelled "casper_library_bus", but this is what is called in
> the "casper_library.mdl" file.
>
> I do see, however, a file called 'casper_library_bus_init.m'. This,
> according to the mlib_devel Github, is supposed to " Save auto-generated
> models as MDL files
> <https://github.com/casper-astro/mlib_devel/commit/3cbd5f97ab1bf4f0b885731d8810759ea15fe912>".
> When I tried running this script in Matlab (not sure if I should do this,
> but I did...), I receive the following errors:
>
> >> casper_library_bus_init
> Warning: Error evaluating 'PreSaveFcn' callback of block_diagram
> 'casper_library_bus'.
> Warning: error opening '/casper_library/casper_library_bus_init'
> Error using save_system (line 38)
> An error or warning occurred during a callback while saving
> '/casper_library/casper_library_bus.slx'. The previously saved version of
> this file (if any) has not been
> changed
>
> Error in casper_library_bus_init (line 285)
> filename = save_system(mdl,[getenv('MLIB_DEVEL_PATH'),
> '/casper_library/', 'casper_library_bus']);
>
> Best,
> Alec
>
> On Thu, Nov 10, 2016 at 4:26 PM, Alec Josaitis <josai...@umich.edu> wrote:
>
>> Dear Glenn,
>>
>> I've never been able to easily browse the DSP blockset in the Simulink
>> library browser, like I can the XPS blockset. The photos below will explain
>> what I mean, but for posterity (in writing), I will say that the sidebar of
>> the Simulink browser easily allows me to peruse the XPS blocks, which
>> appear by name, but the DSP blockset never generates images, and Simulink
>> says the blockset contains "No blocks", but nevertheless I can open the DSP
>> blockset library and all of the blocks/sub-libraries (*except
>> "Downconverter" and "Bus") * are there, empty, but can still be
>> implemented into a model.  When I click on  the Casper DSP "Bus" library to
>> see what is inside, the following error appears:
>>
>> --> Error evaluating 'OpenFcn' callback of SubSystem block
>> 'casper_library/Bus'. -->Undefined function or variable
>> 'casper_library_bus'.
>> ​So, it looks as though I don't actually have access to the bus library.
>> Do you have suggestions on how to fix that, aside from re-downloading the
>> entire mlib_devel library?
>>
>> Best,
>> Alec​
>>
>> On Wed, Nov 9, 2016 at 10:03 PM, G Jones <glenn.calt...@gmail.com> wrote:
>>
>>> Hi Alec,
>>> I was working from memory and got it wrong: the library paths are in
>>> startup.m but shouldn't need to be modified. Are you running ./startsg in
>>> your casper toolflow git directory? When you open the simulink library
>>> browser, can you browse to CASPER DSP Blockset -> bus ?
>>> Glenn
>>>
>>> On Wed, Nov 9, 2016 at 6:08 PM, G Jones <glenn.calt...@gmail.com> wrote:
>>>
>>>> Something is not quite right with your library path setup. Did you
>>>> modify the startsg.sh local script to properly point to your casper
>>>> libraries? You definitely should have the casper bus library if things are
>>>> set up properly.
>>>>
>>>> Glenn
>>>> On Nov 9, 2016 5:59 PM, "Alec Josaitis" <josai...@umich.edu> wrote:
>>>>
>>>>> Dear Glenn,
>>>>>
>>>>> Yes, update_casper_blocks appears to run succesfully. First I ran it
>>>>> inasmuch as it said at the end "don

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

Something is not quite right with your library path setup. Did you modify
the startsg.sh local script to properly point to your casper libraries? You
definitely should have the casper bus library if things are set up properly.

Glenn
On Nov 9, 2016 5:59 PM, "Alec Josaitis" <josai...@umich.edu> wrote:

> Dear Glenn,
>
> Yes, update_casper_blocks appears to run succesfully. First I ran it
> inasmuch as it said at the end "done updating  blocks in ",
> but it does issue warnings at some points. See below.
>
> First, I tried updating my library, and at some point received this:
> updating block xps_library/Shared BRAM/mem/sim_munge_in...
> Simulink:Libraries:RefModificationViolation: Attempt to modify block in a
> linked subsystem. This can only be done by the block or its parent through
> their mask initialization code
> Backtrace 1: reuse_block:51
> Backtrace 2: munge_init:131
> Backtrace 3: shared_bram_mask:119
> Backtrace 4: update_casper_block:161
> Backtrace 5: update_casper_blocks:107
>
> Now, after updating my library, I ran the script on the .slx file
> (poco_wide_12_r316_new); it also completes successfully but only after
> providing these warning messages:
> updating block poco_wide_12_r316_new/fft_wideband_real...
> loading library casper_library_ffts
> MATLAB:MException:MultipleErrors: Error due to multiple causes.
> Backtrace 1: reuse_block:51
> Backtrace 2: fft_stage_n_init:287
> Backtrace 3: reuse_block:51
> Backtrace 4: biplex_core_init:173
> Backtrace 5: reuse_block:51
> Backtrace 6: fft_biplex_real_4x_init:235
> Backtrace 7: reuse_block:51
> Backtrace 8: fft_wideband_real_init:257
> Backtrace 9: update_casper_block:161
> Backtrace 10: update_casper_blocks:107
>
> I then updated my system diagram as you recommended, and received the
> following errors:
>
> Error in 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x':
> Initialization commands cannot be evaluated.
>
> Caused by:
> Error in 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_
> 4x/biplex_core': Initialization commands cannot be evaluated.
> Error in 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_
> 4x/biplex_core/fft_stage_1': Initialization commands cannot be evaluated.
> Error due to multiple causes.
> Unable to load block diagram 'casper_library_bus'
> There is no block named 'casper_library_bus/bus_single_port_ram'
> Do you have a recommendation on how to fix this error?
>
>
> Best,
> Alec
>
> On Mon, Nov 7, 2016 at 10:03 PM, G Jones <glenn.calt...@gmail.com> wrote:
>
>> Hi Alec,
>> Before running casper_xps, update your system diagram (Simulation menu ->
>> Update Diagram).
>> That should pop up messages indicating where the errors are.
>> The error messages you copied sound like there is still some
>> incompatibility between the model and your libraries. Did
>> update_casper_blocks run successfully?
>>
>> Glenn
>>
>> On Mon, Nov 7, 2016 at 6:39 PM, Alec Josaitis <josai...@umich.edu> wrote:
>>
>>> Dear All,
>>>
>>> My apologies, above I meant to include the following hyperlink when I
>>> stated "...this .mdl
>>> <https://github.com/casper-astro/tutorials_devel/blob/master/tut4/poco_wide_12_r316_new.mdl.tar.gz>".
>>> Also, to clarify, I am indeed using the tutorial- recommended versions of
>>> software: Xilinx System Generator 14.7 and MATLAB 2012b.
>>>
>>> Best,
>>> Alec
>>>
>>> On Mon, Nov 7, 2016 at 6:34 PM, Alec Josaitis <josai...@umich.edu>
>>> wrote:
>>>
>>>> Dear Glenn and Jack,
>>>>
>>>> Thanks for the response. I've re-cloned mlib_devel and checked-out the
>>>> proper version ( 4c7ba5efb4
>>>> <https://github.com/casper-astro/mlib_devel/commit/4c7ba5efb421fda1cec0640cf0e3b830a9987640>).
>>>> I then re-downloaded, and un-tarred this .mdl, saved is as a .slx, and then
>>>> opened it in matlab to run update_casper_blocks(bdroot).
>>>> I've copied below the errors that appear. Also, I should note there are
>>>> no .log files in any of the subdirectories inside the directory created by
>>>> casper_xps.
>>>>
>>>> >> casper_xps
>>>> Detected Linux OS
>>>> #
>>>> ##  System Update  ##
>>>> #
>>>> MATLAB:MException:MultipleErrors: Error due to multiple causes.
>>>> Backtrace 1: reuse_block:51
>>>> Backtrace 2: fft_stage_n_init:287
>>>> Backtrace 3: reuse_blo

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

Hi Alec (ccing list for posterity),

I don't know if there's a .fpg for tutorial 4 for ROACH 2 but I would
assume one must be around somewhere.

The error message you're seeing is a bit misleading: 'fpga' is not defined
because of an error in setting it up, so the exit_fail function is being
overly optimistic and trying to clean up the fpga before exiting.

>From ipython try running the lines of poco_init_master.py to see where it's
failing. It looks like it might be having some issue connecting to your
board.

Glenn

On Mon, Nov 7, 2016 at 7:02 PM, Alec Josaitis  wrote:

> Dear Glenn,
>
> Regarding your .fpg solutions: I just realized that the .fpg listed in this
> directory
> 
> is programmed for a Roach, not Roach2! Is there a pre-compiled .fpg
> available for the roach2? The master branch of tutorial 4 is intended to
> run a .bof file, but when I try to run, using the proper .py script, I
> receive the following error:
>
> Connecting to server 192.168.4.20 on port 7147...  FAILURE DETECTED. Log
> entries:
> None
> Traceback (most recent call last):
>   File "poco_init_master.py", line 142, in 
> exit_fail()
>   File "poco_init_master.py", line 21, in exit_fail
> fpga.stop()
> NameError: global name 'fpga' is not defined
>
>
> I believe my katcp library is more-up-to-date than this script wants it to
> be, because my library works with .fpg files, rather than .bof. Is there an
> easy resolution to this which doesn't involve devolving my katcp library?
>
> Best,
> Alec
>
> On Mon, Nov 7, 2016 at 6:39 PM, Alec Josaitis  wrote:
>
>> Dear All,
>>
>> My apologies, above I meant to include the following hyperlink when I
>> stated "...this .mdl
>> ".
>> Also, to clarify, I am indeed using the tutorial- recommended versions of
>> software: Xilinx System Generator 14.7 and MATLAB 2012b.
>>
>> Best,
>> Alec
>>
>> On Mon, Nov 7, 2016 at 6:34 PM, Alec Josaitis  wrote:
>>
>>> Dear Glenn and Jack,
>>>
>>> Thanks for the response. I've re-cloned mlib_devel and checked-out the
>>> proper version ( 4c7ba5efb4
>>> ).
>>> I then re-downloaded, and un-tarred this .mdl, saved is as a .slx, and then
>>> opened it in matlab to run update_casper_blocks(bdroot).
>>> I've copied below the errors that appear. Also, I should note there are
>>> no .log files in any of the subdirectories inside the directory created by
>>> casper_xps.
>>>
>>> >> casper_xps
>>> Detected Linux OS
>>> #
>>> ##  System Update  ##
>>> #
>>> MATLAB:MException:MultipleErrors: Error due to multiple causes.
>>> Backtrace 1: reuse_block:51
>>> Backtrace 2: fft_stage_n_init:287
>>> Backtrace 3: reuse_block:138
>>> Backtrace 4: biplex_core_init:173
>>> Backtrace 5: reuse_block:138
>>> Backtrace 6: fft_biplex_real_4x_init:235
>>> Backtrace 7: gen_xps_files:203
>>> Backtrace 8: run_Callback:155
>>> Backtrace 9: casper_xps:88
>>> Backtrace 10: @(hObject,eventdata)casper_xps
>>> ('run_Callback',hObject,eventdata,guidata(hObject)):0
>>> Simulink:Masking:Bad_Init_Commands: Error in
>>> 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x/biplex_core/fft_stage_1':
>>> Initialization commands cannot be evaluated.
>>> Backtrace 1: reuse_block:138
>>> Backtrace 2: biplex_core_init:173
>>> Backtrace 3: reuse_block:138
>>> Backtrace 4: fft_biplex_real_4x_init:235
>>> Backtrace 5: gen_xps_files:203
>>> Backtrace 6: run_Callback:155
>>> Backtrace 7: casper_xps:88
>>> Backtrace 8: @(hObject,eventdata)casper_xps
>>> ('run_Callback',hObject,eventdata,guidata(hObject)):0
>>> MATLAB:MException:MultipleErrors: Error due to multiple causes.
>>> Backtrace 1: reuse_block:51
>>> Backtrace 2: fft_stage_n_init:287
>>> Backtrace 3: reuse_block:138
>>> Backtrace 4: biplex_core_init:173
>>> Backtrace 5: reuse_block:138
>>> Backtrace 6: fft_biplex_real_4x_init:235
>>> Backtrace 7: gen_xps_files:203
>>> Backtrace 8: run_Callback:155
>>> Backtrace 9: casper_xps:88
>>> Backtrace 10: @(hObject,eventdata)casper_xps
>>> ('run_Callback',hObject,eventdata,guidata(hObject)):0
>>> Simulink:Masking:Bad_Init_Commands: Error in
>>> 'poco_wide_12_r316_new/fft_wideband_real/fft_biplex_real_4x/biplex_core/fft_stage_1':
>>> Initialization commands cannot be evaluated.
>>> Backtrace 1: reuse_block:138
>>> Backtrace 2: biplex_core_init:173
>>> Backtrace 3: reuse_block:138
>>> Backtrace 4: fft_biplex_real_4x_init:235
>>> Backtrace 5: gen_xps_files:203
>>> Backtrace 6: run_Callback:155
>>> Backtrace 7: casper_xps:88
>>> Backtrace 8: @(hObject,eventdata)casper_xps
>>> ('run_Callback',hObject,eventdata,guidata(hObject)):0
>>> Simulink:Masking:Bad_Init_Commands: Error in
>>> 

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

No, these warnings are almost always safe to ignore. You want to look for
error messages. You will always get lots of warning messages.

Glenn

On Fri, Nov 4, 2016 at 5:09 PM, Alec Josaitis <josai...@umich.edu> wrote:

> Dear Casperites,
>
> One other thing I should clarify, is that before the XSG generation fails,
> the following warning is given in Matlab, regarding inconsistent ADC time
> samples. Does this provide insight as to why my compilation fails?
>
>
> Warning: Inconsistent sample times. Sample time (0.25) of signal driving
> input port 1 of 'tut4_update/adc2/tut4_update_adc2_user_data_valid'
> differs from the expected
> sample time ([0, 0]) at this input port.
> > In 
> > /opt/Xilinx/14.7/ISE_DS/ISE/sysgen/bin/lin64/xlCompileGenerateMdl.p>xlCompileGenerateMdl
> at 203
>   In 
> /opt/Xilinx/14.7/ISE_DS/ISE/sysgen/bin/lin64/xlGenerateButton.p>xlGenerateButton
> at 302
>   In gen_xps_files at 323
>   In casper_xps>run_Callback at 158
>   In casper_xps at 88
>   In 
> @(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject))
>
>
> On Fri, Nov 4, 2016 at 5:02 PM, Alec Josaitis <josai...@umich.edu> wrote:
>
>> Dear Glenn,
>>
>> Thanks for getting back to me. Unfortunately, the .log files don't reveal
>> any hints to this issue; below is a print-out of the entire .log file (it
>> is only five lines long). None of these lines refer to
>> 'fpga.is_connected()'.
>>
>> - Version Log
>> --
>> Version Path
>> System Generator/opt/Xilinx/14.7/ISE_DS/ISE/sy
>> sgen
>> Matlab 8.0.0.783 (R2012b)   /usr/local/Matlab/2012b
>> ISE /opt/Xilinx/14.7/ISE_DS/ISE
>>
>>
>> Do you have a copy of tutorial 4 that you were able to successfully
>> compile? Upon receiving it, did you have to update any casper_XPS library
>> blocks, or update the .mdl file in any way before attempting to compile it
>> with the casper_xps script in MATLAB?
>>
>> Best,
>> Alec
>>
>> On Wed, Nov 2, 2016 at 3:29 PM, G Jones <glenn.calt...@gmail.com> wrote:
>>
>>> Hi Alec,
>>> Your compilation error indicates that running system generator failed.
>>> You need to look in the directory created with the design name for the
>>> system generator logs to see where the error occurred. I can't remember the
>>> exact name but dig through the sub directories for .log files and the
>>> search for "error" to see if you can find an error message.
>>> I'm not familiar enough with the casper_fpga library to offer much
>>> advice. Does fpga.is_connected() return True?
>>>
>>> Does the .fpg file look the same as the ones that work for you?
>>>
>>>
>>> Glenn
>>> Dear Casperites,
>>>
>>> I've been trying to complete tutorial 4
>>> <https://casper.berkeley.edu/wiki/Tutorial_Wideband_Pocket_Correlator>
>>> for the Roach2, and have run into difficulty compiling either the .slx
>>> <https://github.com/casper-astro/tutorials_devel/blob/tutorials_update_2016/tut4/poco_wide_12_r316_new.slx.r2013a.tar.gz>
>>> or .mdl
>>> <https://github.com/casper-astro/tutorials_devel/blob/tutorials_update_2016/tut4/poco_wide_12_r316_new.mdl.tar.gz>files
>>> given for the Roach 2, or uploading the precompoliled .fpg
>>> <https://github.com/casper-astro/tutorials_devel/blob/tutorials_update_2016/tut4/poco_wide_1kat.fpg>
>>> file onto my Roach2 (using either the python scripts given or simply by
>>> command-line uploading the .fpg using ipython). My error messages are
>>> attached in this Google Drive document.
>>> <https://docs.google.com/document/d/1RY5LSS7mRx3o2Zm6Gyy_a8jhEjJr2bM1k9CCN9ov0bw/edit?usp=sharing>
>>>
>>> For tutorials 1-3 I have had no trouble compiling the .slx files and
>>> upload the corresponding .fpg files to my Roach2.
>>>
>>> I've made sure in the .slx I cite above (for tutorial 4) that the
>>> XSG_core_config block does not have a broken link and that the settings are
>>> as follows:
>>>
>>>
>>>- Hardware platform: Roach2:sx475t
>>>- User IP clock source: adc0_clk
>>>- User IP clock rate (MHz): 200, (and that the adc1 and adc0 are
>>>correspondingly clocked to 800 MHz)
>>>- Sample period: 1
>>>- Synthesis tool: XST
>>>
>>> Any advice on how I can complete tutorial 4?
>>>
>>>
>>> Best,
>>>
>>> Alec
>>>
>>>
>>>
>>>
>>
>

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

Hi Alec,
Sorry if it wasn't clear, my answers were to your two separate queries, not
all together:

To diagnose the compilation problem, you need to dig through the
tut4_update directory that was created by casper_xps in the same directory
as the tut4_update.slx file you are compiling and find all the .log files
(be sure to look in all the subdirectories) and then search those .log
files for "error"


For your problem of not being able to program the fpga, that's where I
suggest running fpga.is_connected() to make sure you are properly
communicating with the FPGA aside from trying to program it. Similarly,
look at the .fpg file vs. the ones that seem to be working and see if
anything obvious is amiss. I suspect a version incompatibility between the
toolflow used to create the tutorial 4 .fpg file and your casper_fpga
python library or katcp library.

Glenn

On Fri, Nov 4, 2016 at 5:02 PM, Alec Josaitis <josai...@umich.edu> wrote:

> Dear Glenn,
>
> Thanks for getting back to me. Unfortunately, the .log files don't reveal
> any hints to this issue; below is a print-out of the entire .log file (it
> is only five lines long). None of these lines refer to
> 'fpga.is_connected()'.
>
> - Version Log
> --
> Version Path
> System Generator/opt/Xilinx/14.7/ISE_DS/ISE/sysgen
> Matlab 8.0.0.783 (R2012b)   /usr/local/Matlab/2012b
> ISE /opt/Xilinx/14.7/ISE_DS/ISE
>
>
> Do you have a copy of tutorial 4 that you were able to successfully
> compile? Upon receiving it, did you have to update any casper_XPS library
> blocks, or update the .mdl file in any way before attempting to compile it
> with the casper_xps script in MATLAB?
>
> Best,
> Alec
>
> On Wed, Nov 2, 2016 at 3:29 PM, G Jones <glenn.calt...@gmail.com> wrote:
>
>> Hi Alec,
>> Your compilation error indicates that running system generator failed.
>> You need to look in the directory created with the design name for the
>> system generator logs to see where the error occurred. I can't remember the
>> exact name but dig through the sub directories for .log files and the
>> search for "error" to see if you can find an error message.
>> I'm not familiar enough with the casper_fpga library to offer much
>> advice. Does fpga.is_connected() return True?
>>
>> Does the .fpg file look the same as the ones that work for you?
>>
>>
>> Glenn
>> Dear Casperites,
>>
>> I've been trying to complete tutorial 4
>> <https://casper.berkeley.edu/wiki/Tutorial_Wideband_Pocket_Correlator>
>> for the Roach2, and have run into difficulty compiling either the .slx
>> <https://github.com/casper-astro/tutorials_devel/blob/tutorials_update_2016/tut4/poco_wide_12_r316_new.slx.r2013a.tar.gz>
>> or .mdl
>> <https://github.com/casper-astro/tutorials_devel/blob/tutorials_update_2016/tut4/poco_wide_12_r316_new.mdl.tar.gz>files
>> given for the Roach 2, or uploading the precompoliled .fpg
>> <https://github.com/casper-astro/tutorials_devel/blob/tutorials_update_2016/tut4/poco_wide_1kat.fpg>
>> file onto my Roach2 (using either the python scripts given or simply by
>> command-line uploading the .fpg using ipython). My error messages are
>> attached in this Google Drive document.
>> <https://docs.google.com/document/d/1RY5LSS7mRx3o2Zm6Gyy_a8jhEjJr2bM1k9CCN9ov0bw/edit?usp=sharing>
>>
>> For tutorials 1-3 I have had no trouble compiling the .slx files and
>> upload the corresponding .fpg files to my Roach2.
>>
>> I've made sure in the .slx I cite above (for tutorial 4) that the
>> XSG_core_config block does not have a broken link and that the settings are
>> as follows:
>>
>>
>>- Hardware platform: Roach2:sx475t
>>- User IP clock source: adc0_clk
>>- User IP clock rate (MHz): 200, (and that the adc1 and adc0 are
>>correspondingly clocked to 800 MHz)
>>- Sample period: 1
>>- Synthesis tool: XST
>>
>> Any advice on how I can complete tutorial 4?
>>
>>
>> Best,
>>
>> Alec
>>
>>
>>
>>
>

Re: [casper] Roach2 Tutorial 4 Troubles (Can't Compile .slx or Upload .fpg)

[G Jones]

Hi Alec,
Your compilation error indicates that running system generator failed. You
need to look in the directory created with the design name for the system
generator logs to see where the error occurred. I can't remember the exact
name but dig through the sub directories for .log files and the search for
"error" to see if you can find an error message.
I'm not familiar enough with the casper_fpga library to offer much advice.
Does fpga.is_connected() return True?

Does the .fpg file look the same as the ones that work for you?


Glenn
Dear Casperites,

I've been trying to complete tutorial 4
 for
the Roach2, and have run into difficulty compiling either the .slx

or .mdl
files
given for the Roach 2, or uploading the precompoliled .fpg

file onto my Roach2 (using either the python scripts given or simply by
command-line uploading the .fpg using ipython). My error messages are
attached in this Google Drive document.


For tutorials 1-3 I have had no trouble compiling the .slx files and upload
the corresponding .fpg files to my Roach2.

I've made sure in the .slx I cite above (for tutorial 4) that the
XSG_core_config block does not have a broken link and that the settings are
as follows:


   - Hardware platform: Roach2:sx475t
   - User IP clock source: adc0_clk
   - User IP clock rate (MHz): 200, (and that the adc1 and adc0 are
   correspondingly clocked to 800 MHz)
   - Sample period: 1
   - Synthesis tool: XST

Any advice on how I can complete tutorial 4?


Best,

Alec

Re: [casper] 32 Channel PFB and Wideband Real FFT . . .

[G Jones]

Hi Randy,
I think the issue is that you are processing 16 samples per FPGA clock for
VEGAS (if I remember right), so I expect you'll need to hand craft an FFT
out of the FFT direct block and twiddle blocks. It might be easier to use a
xilinx block in this case, but I haven't actually looked at what's
available.
Glenn

On Mon, Jul 18, 2016 at 1:04 PM, Randy McCullough  wrote:

> All,
>
> We're currently in the process of adding incoherent and coherent
> de-dispersion
> pulsar modes to our ROACH 2-based VEGAS backend and have hit a stumbling
> block.  We've built all designs ranging from 8,192 channels down to 64
> channels,
> but when attempting to implement a 32-channel design the standard Wideband
> Real FFT block breaks.  Has anyone successfully implemented a 32 channel
> PFB/FFT
> pair on a ROACH 2 platform?
>
> Randy
>
>

[casper] Looking for iADC for long-term loan

[G Jones]

Hi,
Does anyone have a pair of iADCs (or other 1GHz ADC ZDOK cards) gathering
dust that they wouldn't mind lending me for a small project?
Thanks,
Glenn

Re: [casper] Trouble getting 10GbE working

[G Jones]

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> 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] Unconnected output block warnings when compiling with dac_mkid

[G Jones]

Regarding the parallel to serial converter, so far I haven't experienced a
need to set the configuration registers on the DAC, so I just deleted that
block inside the yellow block and tied the output ports to constants.
Obviously not a good solution if you do need the configuration registers.
Not sure about the warning.

Glenn
On Sep 27, 2015 7:02 PM, "Tubbesing, Richard G" 
wrote:

> Hello,
>
>
> I am a graduate student at ERAU using ROACHs for my research project.
>
>
> I have been trying to use the toolflow for some time now and I have run in
> to many issues.
>
>
> Currently, I have the latest mlib_devel from the casper-astro git.
>
>
> When I compile a design that includes the dac_mkid yellow block, I am
> having two issues:
>
>
> 1) If the yellow block is placed fresh from the library into the model and
> then the model is compiled, I get an error related to initializing mask
> parameters on the "parallel_to_serial" block that is in a subsystem of the
> dac_mkid block.
>
>
> I can fix this if I replace the "parallel_to_serial" with one from the
> library or simply copying it and pasting itself back in to the model.
>
>
> Is there anyway to fix this? I have a work around but it is rather
> annoying to go in and replace those to blocks whenever I use the dac_mkid
> yellow block.
>
>
>
> 2) I am getting many warnings when I compile. They look like the following
> two:
>
>
> Warning: Output port 1 of
> 'adc_to_dac_test/dac_mkid1/adc_to_dac_test_dac_mkid1_dac_data_i1' is not
> connected.
> > In
> /opt/Xilinx/14.6/ISE_DS/ISE/sysgen/bin/lin64/xlCompileGenerateMdl.p>xlCompileGenerateMdl
> at 203
>   In
> /opt/Xilinx/14.6/ISE_DS/ISE/sysgen/bin/lin64/xlGenerateButton.p>xlGenerateButton
> at 302
>   In gen_xps_files at 323
>   In casper_xps>run_Callback at 158
>   In casper_xps at 88
>   In
> @(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject))
>
> Warning: Output port 1 of
> 'adc_to_dac_test/dac_mkid1/adc_to_dac_test_dac_mkid1_dac_data_q0' is not
> connected.
> > In
> /opt/Xilinx/14.6/ISE_DS/ISE/sysgen/bin/lin64/xlCompileGenerateMdl.p>xlCompileGenerateMdl
> at 203
>   In
> /opt/Xilinx/14.6/ISE_DS/ISE/sysgen/bin/lin64/xlGenerateButton.p>xlGenerateButton
> at 302
>   In gen_xps_files at 323
>   In casper_xps>run_Callback at 158
>   In casper_xps at 88
>   In
> @(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject))
>
>
> Can anyone shed some light on this? The model will compile successfully
> but I think these warnings are preventing the actual design from working on
> the ROACH.
>
>
> Thank you,
>
>
> -Richard T.
>
>
>
>

Re: [casper] ROACH2 one_gbe block losing data on reception

[G Jones]

Hi Henno,
Thanks for replying. I meant to mention the simulink clock is 250 MHz and
the design meets timing. The ultimate goal is loading waveforms into the
DRAM since there isn't a CPU DRAM interface for ROACH2 yet, so any speed
better than loading via KATCP would be great. But I've tried delays of up
to 10 ms between each packet (i.e. down to about 100 KB/s), and am still
seeing this behavior. The data loss fraction doesn't seem to improve
substantially with reduced data rate. This leads me to suspect some sort of
signal integrity issue, but I'm not sure where.

Glenn
On Jul 28, 2015 12:50 AM, Henno Kriel he...@ska.ac.za wrote:

 Hi Glen,

 I assume you are running your fabric  125MHz? What is the data rate you
 are trying to sustain?

 HK

 On Mon, Jul 27, 2015 at 10:06 PM, G Jones glenn.calt...@gmail.com wrote:

 Hi,
 I'm experimenting with the one_gbe block on ROACH2. So far data
 transmission looks flawless, I can capture all the bytes I send. However,
 receiving data from a computer seems to result in missing data.
 My design is very simple, I have rx_ack tied high, and then counters on
 rx_val and the rising edge of rx_eof and also on rx_overrun and rx_badframe.

 If I just send a single packet, all looks good, the rx_val counter shows
 the number of bytes I sent, and rx_eof shows one packet received. But when
 I try to send a sequence of packets, I end up with the rx_val counter
 showing fewer bytes than I sent, by about ~ 0.5-5% depending on the exact
 combination of parameters I use in sending packets. Sometimes all the ~1024
 packets arrive, as indicated by the rx_eof counter, but other times it
 seems 1-3 are missing.

  I see consistent results whether the packet payload is 1024 bytes, 4096
 bytes, or 8192 bytes.

 I never see any counts on the rx_overrun or rx_badframe line.

 I am using sendall to send the packets from the host computer, and it
 reports that all bytes are being sent, so I assume it's not dropping them
 on the way outbound (plus it seems like it would be weird for the host
 computer to send partial packets).

 I've tried this test with two different network adapters (both directly
 connected to the ROACH2 fabric ethernet port, and with various lengths of
 CAT 6 ethernet cables.

 Has anyone used the one_gbe block in this way? Am I missing something?

 Thanks,
 Glenn




 --
 Kind regards,
 Henno Kriel

 Manager: Hardware Engineering
 SKA South Africa
 (p) +27 (0)21 506 7374 (direct)
 (m) +27 (0)84 504 5050
 web: www.ska.ac.za

[casper] ROACH2 one_gbe block losing data on reception

[G Jones]

Hi,
I'm experimenting with the one_gbe block on ROACH2. So far data
transmission looks flawless, I can capture all the bytes I send. However,
receiving data from a computer seems to result in missing data.
My design is very simple, I have rx_ack tied high, and then counters on
rx_val and the rising edge of rx_eof and also on rx_overrun and rx_badframe.

If I just send a single packet, all looks good, the rx_val counter shows
the number of bytes I sent, and rx_eof shows one packet received. But when
I try to send a sequence of packets, I end up with the rx_val counter
showing fewer bytes than I sent, by about ~ 0.5-5% depending on the exact
combination of parameters I use in sending packets. Sometimes all the ~1024
packets arrive, as indicated by the rx_eof counter, but other times it
seems 1-3 are missing.

 I see consistent results whether the packet payload is 1024 bytes, 4096
bytes, or 8192 bytes.

I never see any counts on the rx_overrun or rx_badframe line.

I am using sendall to send the packets from the host computer, and it
reports that all bytes are being sent, so I assume it's not dropping them
on the way outbound (plus it seems like it would be weird for the host
computer to send partial packets).

I've tried this test with two different network adapters (both directly
connected to the ROACH2 fabric ethernet port, and with various lengths of
CAT 6 ethernet cables.

Has anyone used the one_gbe block in this way? Am I missing something?

Thanks,
Glenn

[casper] SOLVED: ROACH 2 rebooting spontaneously

[G Jones]

Hi,
I just received a new ROACH 2 and was starting out by hooking up the USB
FTDI port to my Windows 8.1 laptop. I let it install a driver for the FTDI
chip and all seemed fine, I could see the uboot prompt etc. However, then
the board started rebooting itself every ~ 10 seconds. I suspected a
hardware problem, but eventually I got my DHCP server configured to give
the ROACH an IP address. I disconnected the USB cable from my laptop and
rebooted the ROACH 2, after which I was able to connect by ssh and KATCP
and everything seemed fine. I then moved the USB cable to a CentOS computer
and that seems to work without causing reboots.
So the moral of the story is: beware trying to use the default FTDI Windows
8.1 driver that windows installs for you.

Glenn

Re: [casper] Roach1 Host name lookup error.

[G Jones]

I ran into this a lot when trying to use the sdcard filesystem. I think the
problem is that the filesystem is ext2 or something old like that which is
prone to corruption if the system is hard rebooted. My advice is use NFS
file system.
On May 20, 2015 1:20 PM, Brad Dober do...@sas.upenn.edu wrote:

 Hi Casperites,

 I have a Roach1 which is booting from an SD card.
 I booted it up yesterday, and it was displaying the STALE NFS handle
 error that other people have seen in the past (which suggested a corrupt
 flash card). I ran fsck and fixed several errors, and when rebooting, the
 stale nfs handle error went away. However, now the ROACH could not connect
 to the network.

 When I run ifconfig 128.91.46.20 netmask 255.255.248.0 gateway 128.91.4,
 I get:

 gateway: Host name lookup failure


 root@(none):~# hostname -v

 (none)

 and

 root@(none):~# hostname --fqdn

 hostname: Host name lookup failure


 Any ideas on what could be causing this?

 Brad Dober
 Ph.D. Candidate
 Department of Physics and Astronomy
 University of Pennsylvania
 Cell: 262-949-4668

Re: [casper] Roach1 not working

[G Jones]

Note that for recursive, you need -R not -r

On Fri, May 8, 2015 at 3:55 PM, Nishanth Shivashankaran nshiv...@asu.edu
wrote:

 Hi All,

Thanks for the reply. I have the exports set to

 /home/nfs/roach1/current   192.168.70.0/24(sync,rw,no_root_squash)

 and it did not work. I changed the permissions of all the files in the
 boot and current to chmod -r 777 and it still gives me the same error.

 thanks and regards,
 Nishanth





 On Fri, May 8, 2015 at 6:18 AM, John Ford jf...@nrao.edu wrote:

 Hi.

 error 13 is permission denied.  Probably your exports file isn't quite
 right.  Note that you have to allow root permission on the mount.
 Something like this should be in /etc/exports:

 /home/nfs/roach1/current 192.168.40.0/24(sync,rw,no_root_squash)

 John


  Hi All,
 
 I used the usb wriggler and ito load the bootloader and now I am
 seeing
  data comming out of the serial terminal as before.
  But the roach is still not booting properly. I am trying to boot the
 roach
  through nfs boot and I am seeing this at the terminal. Please can any
 tell
  me how to fix this error.
 
  Thanks
  Nishanth
 
  U-Boot 2008.10-svn3231 (Jul 15 2010 - 14:58:38)
 
  CPU:   AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133, OPB=66,
 EBC=66
  MHz)
 No Security/Kasumi support
 Bootstrap Option C - Boot ROM Location EBC (16 bits)
 32 kB I-Cache 32 kB D-Cache
  Board: Roach
  I2C:   ready
  DTT:   1 FAILED INIT
  DRAM:  (spd v1.2) dram: notice: ecc ignored
   1 GB
  FLASH: 64 MB
  USB:   Host(int phy) Device(ext phy)
  Net:   ppc_4xx_eth0
 
  Roach Information
  Serial Number:040114
  Monitor Revision: 8.3.1698
  CPLD Revision:8.0.1588
 
  type run netboot to boot via dhcp+tftp+nfs
  type run soloboot to run from flash without network
  type run mmcboot to boot using filesystem on mmc/sdcard
  type run usbboot to boot using filesystem on usb
  type run bit to run tests
 
  Hit any key to stop autoboot:  0
  Waiting for PHY auto negotiation to complete done
  ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
  BOOTP broadcast 1
  *** Unhandled DHCP Option in OFFER/ACK: 28
  *** Unhandled DHCP Option in OFFER/ACK: 28
  DHCP client bound to address 192.168.40.8
  Using ppc_4xx_eth0 device
  TFTP from server 192.168.40.1; our IP address is 192.168.40.8
  Filename 'uImage'.
  Load address: 0x40
  Loading:
 #
   ##
  done
  Bytes transferred = 1390149 (153645 hex)
  WARNING: adjusting available memory to 3000
  ## Booting kernel from Legacy Image at 0040 ...
 Image Name:   Linux-2.6.25-svn3489
 Image Type:   PowerPC Linux Kernel Image (gzip compressed)
 Data Size:1390085 Bytes =  1.3 MB
 Load Address: 
 Entry Point:  
 Verifying Checksum ... OK
 Uncompressing Kernel Image ... OK
  id mach(): done
  MMU:enter
  MMU:hw init
  MMU:mapin
  MMU:setio
  MMU:exit
  setup_arch: enter
  setup_arch: bootmem
  ocp: exit
  arch: exit
  Linux version 2.6.25-svn3489 (dave@lapster) (gcc version 4.2.2) #6 Fri
 Aug
  12 09:36:28 SAST 2011
  AMCC PowerPC 440EPx Roach Platform
  Zone PFN ranges:
DMA 0 -   262143
Normal 262143 -   262143
  Movable zone start PFN for each node
  early_node_map[1] active PFN ranges
  0:0 -   262143
  Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
  260096
  Kernel command line: console=ttyS0,115200
  mtdparts=physmap-flash.0:1792k(linux),256k@0x1c(fdt),8192k@0x20
  (root),p
  PID hash table entries: 4096 (order: 12, 16384 bytes)
  console [ttyS0] enabled
  Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
  Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
  Memory: 1036416k available (2084k kernel code, 720k data, 132k init, 0k
  highmem)
  Mount-cache hash table entries: 512
  BORPH version CVS-$Revision: 1.10 $ Initialized
  net_namespace: 152 bytes
  NET: Registered protocol family 16
 
  PCI: Probing PCI hardware
  SCSI subsystem initialized
  usbcore: registered new interface driver usbfs
  usbcore: registered new interface driver hub
  usbcore: registered new device driver usb
  NET: Registered protocol family 2
  IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
  TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
  TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
  TCP: Hash tables configured (established 131072 bind 65536)
  TCP reno registered
  hwrtype_roach version CVS-$Revision: 1.1 $ registered
  JFFS2 version 2.2. (NAND) ??? 2001-2006 Red Hat, Inc.
  io scheduler noop registered (default)
  Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
 disabled
  serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
  serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
  serial8250: ttyS2 at MMIO 0x0 (irq = 35) is a 16550A
  serial8250: ttyS3 at MMIO 

Re: [casper] Skewed data samples

[G Jones]

Hi Tom,
Wouldn't that just cause extra power in the DC bin? Or do the samples still
have zero mean?

Glenn

On Fri, Apr 24, 2015 at 7:32 PM, Kuiper, Thomas (3266) kui...@jpl.nasa.gov
wrote:

 Does any have an idea what might happen to a PFB if the data samples have
 a slight skewness towards negative values?  Maybe someone has the answer
 before I start modeling.

 Thank

 Tom

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

[G Jones]

Check your java heap size setting in MATLAB. The default value is often way
too low. Search the mailing list archive for more details.
On Apr 7, 2015 2:02 AM, Chaudhari Sandeep C. s...@gmrt.ncra.tifr.res.in
wrote:

 Dear All,

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

 The installation details are as follows :

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



 Thanks  regards,
 Sandeep C. Chaudhari
 GMRT,TIFR

Re: [casper] One_GbE on R2

[G Jones]

Hi Brad,
It works the same as the 10 GbE port, so the documentation for that block
applies directly.
GLenn

On Mon, Apr 6, 2015 at 11:19 AM, Brad Dober do...@sas.upenn.edu wrote:

 Hi Casperites,

 Sorry to bother you, but I'm wondering if anyone has used the one GbE
 block/port on the Roach2.
 I'm trying to get started sending/receiving data and don't see a
 description page on the wiki. Is there a simple example out there that I
 can look at to help me get started?

 Cheers,

 Brad Dober
 Ph.D. Candidate
 Department of Physics and Astronomy
 University of Pennsylvania
 Cell: 262-949-4668

Re: [casper] problems with Valon sythn + ROACHI

[G Jones]

Do you have a spectrum analyzer to see how much the output of the Valon
changes when locked vs unlocked? Have you tried running the Valon at
different output frequencies when locked to see if a lower clock rate makes
your design work again?

On Mon, Mar 23, 2015 at 1:54 PM, Louis Dartez louisdar...@gmail.com wrote:

 Hi Casperites,

 For our project we are using a ROACHI with this Valon 5008 Synthesizer
 http://valontechnology.com/5008.html in our 4-input correlator system.
 We are currently seeing an issue with what seems to be our synthesizer’s
 10MHz ref input. When we drive the ROACHI correlator without the 10MHz ref
 then we have no issues. But when we plug in the 10MHz ref, our TX buffers
 overflow and the system locks up. Resetting the system (with the 10MHz ref
 plugged in) only temporarily fixes the issue (only a few UDP packets get
 out of the buffer before it locks up again). We have four ROACHI’s all
 running identical setups/firmware and only one of them exhibits this
 problem.

 Has anyone else seen anything like this?

 L

 Louis P. Dartez

 Graduate Research Assistant

 STARGATE

 Center for Advanced Radio Astronomy

 University of Texas Rio Grande Valley

 (956) 372-5812

Re: [casper] ROACH2 MKID Block and DDR3 DRAM

[G Jones]

Hi Jonathon,
Are you able to share your state machine that moves data from 10 GbE to
DRAM? Sounds useful!

Thanks,
Glenn

On Tue, Mar 10, 2015 at 5:04 PM, Gard, Johnathon D. johnathon.g...@nist.gov
 wrote:

  Hello Everyone,


  Just an update on what I have worked out. Thank you Wesely New for the
 idea, that worked once I got the correct multipliers and dividers in the

 instantiation of the MMCM. To get the correct numbers, I created an ISE
 project and IP Core project (you may not need the ISE project to create the
 IP Core project, but I am just starting with ISE) and created an MMCM IP
 core and pulled the values out of that. For instance, we are running the
 MKID ADC/DAC board at 512 MHz, the clock we are syncing to is half of that,
 256MHz , so we want a 1 to 1 MMCM:

 CLKFBOUT_MULT_F = 8.00

 DIVCLK_DIVIDE = 2

 CLKIN1_PERIOD = 4.00

 CLKOUT0_DIVIDE_F = 4.00

 CLKOUT1_DIVIDE = 4

 CLKOUT2_DIVIDE = 4

 CLKOUT3_DIVIDE = 4


  I hope this helps. I have done a loop test of sending a signal into the
 ADC and then just passing it through the FPGA back out to the DAC and on a
 oscilloscope I do not see anything unusual except for the digitization
 noise.


  Running the entire firmware to 480MHz is rather impressive. I would
 imagine you are running into timing issues beyond that which is not at all
 surprising. Unless you meant the ADC/DAC running at 480MHz and the FPGA
 itself being clocked at 240MHz.


  At the moment I have written a state machine to interface between the
 10Gbe rx port and the DDR3 DRAM block. This is a work around for the PPC to
 DRAM interface. I guess it also opens up the ability to send data to the
 ROACH2 over the 10Gbe link. Our link is only sending data to the PC it is
 connected to.


  I hope this helps.


  Johnathon Gard

 National Institute of Standards and Technology

 Quantum Sensors Project​​



  --
 *From:* Nishanth Shivashankaran nshiv...@asu.edu
 *Sent:* Friday, March 6, 2015 11:20 AM
 *To:* Brad Dober
 *Cc:* Wesley New; Gard, Johnathon D.; johnathon.g...@gmail.com;
 casper@lists.berkeley.edu
 *Subject:* Re: [casper] ROACH2 MKID Block and DDR3 DRAM

Hi All,

 I have replaced the DCM with the MMCM, and the firmware works till
 about 480MHz. I tried to play with other multipliers and dividers values, I
 get it to compile for higher frequencies but the ADC data gets clipped when
 I set the value of the DIVCLK_DIVIDE greater than 1. If anyone can tell me
 why the ADC samples has a clipped waveform when I set it to greater than 1,
 I would really appreciate it. Currently, I am trying to figure out a way to
 use two MMCM's and play with 2 sets of multiplier and divider to see if it
 gets rid of the weird clipping problem so that I can clock it greater than
 500Mhz.

 The files attached has the value of DIVCLK_DIVIDE set to 1 and the
 Firmware codes compile to about 480 MHz and there is no clipping observed.

  Warm regards,
  Nishanth

 On Fri, Mar 6, 2015 at 9:48 AM, Brad Dober do...@sas.upenn.edu wrote:

 Nishanth at ASU has been working on getting the MKID ADC/DAC working on
 the ROACH2.

  The DAC is fully functional, and the ADC works up to CLK frequency of
 480 MHz, then some NCO clock errors pop up.

  We are also interested in the PPC interface to the DRAM.
 Feel free to contact Nishanth and I to talk about this further.


  Brad Dober
 Ph.D. Candidate
 Department of Physics and Astronomy
 University of Pennsylvania
 Cell: 262-949-4668

 On Fri, Mar 6, 2015 at 2:56 AM, Wesley New wes...@ska.ac.za wrote:

 Hi Johnathan.

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

  You will need to edit this file:


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

  The DCM is at the end of the file.

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


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

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

  Regards

  Wesley


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



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

   Hello Everyone,

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

 OS = Ubuntu 14.04.2 LTS

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

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





 First thing, syncing the FPGA clock to the ADC/DAC clock. Using the
 mkid adc or dac blocks from the xps library and selecting any one of the
 

Re: [casper] Reading ROACH2 FPGA BRAMs on PowerPC

[G Jones]

Hi Danny,
Have you seen this page on the wiki?
https://casper.berkeley.edu/wiki/FPGA_Device_Driver_Memo
The example code in the links provided there worked well as a good starting
point.

Glenn

On Mon, Feb 16, 2015 at 10:04 PM, Danny Price dpr...@cfa.harvard.edu
wrote:

 Hi all

 I'd like to read data from the FPGA on the ROACH2 powerpc, then pack it
 into UDP and send it out over Ethernet. Is there a straightforward and
 reasonably efficient way to read registers/bram from the FPGA on the ROACH2
 powerpc? Better yet, has anyone implemented something already that they're
 happy to share? We need a ~0.5MB transfer, triggered when a register is
 incremented (once per second), so speed shouldn't be a major issue.

 I know on the ROACH1 the BRAMs were available in /proc, and that the new
 tcpborphserver3 on the ROACH2 memory maps through the 'device nodes' in
 /dev/roach, but I'm not clear on how to read desired registers on the PPC
 though this...

 Thanks
 Danny

Re: [casper] Linux Valon Synthesizer

[G Jones]

Make sure you have the right permissions for the port, i.e. do:
ls -l /dev/ttyUSB0
and make sure you have permissions.
On a lot of systems, the ttyUSB* are in the dialout group, so if you add
your username to that group and log out and back in, you should be able to
access it.

Glenn

On Thu, Dec 11, 2014 at 3:29 PM, Matías Vidal Valladares 
matimetalvi...@hotmail.cl wrote:

 Hi everyone,

 I'm trying to use de Linux Valon Synthesizer made by Patrick Brandt (link
 below), but i have problems with the port.
 I have the following error:
 SerialException: Could not configure port: (5, 'Input/output error')

 If i have a Roach plugged to ttyUSB0, what parameter should i use when i
 declare an object of type Synthesizer?

 I have Ubuntu 14.04, and i run the code with ipython.

 Link: https://github.com/nrao/ValonSynth


 *Matías Vidal Valladares.*

Re: [casper] Problem about the adc frequency in PAPER model.

[G Jones]

Also, at least for many ADC boards that have a PPS input, the signal is
connected to a 50 ohm resistor to ground and then goes into a TTL to LVDS
converter chip. You mentioned 3 Vpp and 0 V offset, so that sounds like the
signal is mostly at -1.5 V and then pulses up to +1.5V. I would suggest a
positive only waveform, 0 V pulsing up to 3 V would be better.

Glenn

On Fri, Nov 7, 2014 at 12:12 PM, Richard Black aeldstes...@gmail.com
wrote:

 Dan,

 We aren't using a square wave. It's a pulse function, but that pulse's
 shape can be easily described as a very thin square pulse.

 However, you are saying that the pulse is high for only 1 us? That is much
 shorter than what we are doing. I'll see if I can twiddle that down.

 Thanks,

 Richard Black

 On Fri, Nov 7, 2014 at 10:09 AM, Dan Werthimer d...@ssl.berkeley.edu
 wrote:

 you mentioned your 1 PPS is a square wave.
 that's different from everyone else's 1 PPS:

 standard 1 PPS systems output a pulse that is
 high for about 1 uS.  (extremely low duty cycle).

 i don't know if a square wave could be a problem - my guess
 is that the correlator design uses an edge detection block,
 so is only sensitive to edges, not levels, but it might
 be worth investigating.

 best wishes,

 dan


 On Fri, Nov 7, 2014 at 9:03 AM, Richard Black aeldstes...@gmail.com
 wrote:
  Hi all,
 
  Haven't heard anything for a while, so I thought I would add some more
  detail about our system setup to see if it might shed some light on the
  problem:
 
  1 PPS Signal
  -
  Square pulse
  Frequency: 1 Hz
  Amplitude: 3 Vpp
  Offset: 0 V
  Width: 10 ms
  Edge Time: 5 ns
 
  ADC Clock
  -
  CW Tone
  Frequency: 200 MHz
  Power: -9 dBm
 
  For David, are there any red flags with our UBoot version or ROACH CPLD?
  Here they are again for reference:
 
  From serial interface after ROACH reboot
  ==
  U-Boot 2011.06-rc2-0-g2694c9d-dirty (Dec 04 2013 - 20:58:06)
  ...
  CPLD: 2.1
  ==
 
  Thanks!
 
 
  Richard Black
 
  On Tue, Nov 4, 2014 at 12:05 PM, Richard Black aeldstes...@gmail.com
  wrote:
 
  Hi David,
 
  Comments below:
 
  Richard Black
 
  On Mon, Nov 3, 2014 at 3:51 PM, David MacMahon 
 dav...@astro.berkeley.edu
  wrote:
 
  Hi, Richard,
 
  On Nov 3, 2014, at 11:47 AM, Richard Black wrote:
 
   So, it's been a little while now, but not much has changed yet.
 We've
   gotten Chipscope working, and, so far, there aren't any red flags
 with the
   FPGA firmware 10-GbE control signals.
 
  That's good to know, although maybe in some way it would have been
 nice
  if you had found some red flags.
 
   We also confirmed that the bitstream we are using is in fact
   roach2_fengine_2013_Oct_14_1756.bof.gz, so that is unfortunately
 not the
   problem.
 
  At least you are using a known good BOF file, so that eliminates a
 source
  of potential errors.
 
   I also took a look at the ROACH2 PPC setup: we pulled from the .git
   repository on February 12, 2014 (commit number =
   e14df9016c3b7ccba62cc6d0cae05405f4929c94). There haven't been any
 changes to
   that repository since August 2013, so unless the SKA-SA ROACH-2s
 are using a
   pull from before then, I don't think that is our issue.
 
  We use our own homegrown NFS root filesystem for the ROACH2s, so I
 can't
  comment on the status of the one you refer to
  (https://github.com/ska-sa/roach2_nfs_uboot.git).  I am more
 interested in
  the U-Boot version you have (see
 https://github.com/ska-sa/roach2_uboot.git)
  and which version of the ROACH2 CPLD image you are using (not sure
 where to
  get this).  I think these are unlikely to be problematic, but we've
 already
  checked all the likely problems.
 
 
  When I rebooted the ROACH-2, I got the following header for U-Boot:
 
  U-Boot 2011.06-rc2-0-g2694c9d-dirty (Dec 04 2013 - 20:58:06)
  ...
  CPLD: 2.1
 
  Hope this is informative.
 
 
 
 
   We also tried out Jason Manley's suggestion of delaying the
 enabling of
   the 10-GbE cores to ensure that the sync pulse propagated through
 the entire
   system before buffering up data, but the problem persisted.
 
  Do you have an external 1 PPS sync pulse connected or have you tried
 the
  latest rb-papergpu software that supports a software-generated
 sync?  The
  paper_feng_init.rb script already disables the data flow to the 10
 GbE cores
  until the sync pulse has propagated through and the cores have been
 taken
  out of reset.
 
 
  We are using an external 1 PPS sync pulse. However, we are certain that
  it's set up correctly. Although, this could just be me grasping at
 straws
  since nothing else seems to solve the problem. How would we go about
 setting
  up the software-generated pulse?
 
 
  Does the latest rb-papergpu code show that the ADC clocks (MMCMs) are
  locked?  Does it estimate the clock frequency correctly?  Does
  adc16_dump_chans.rb show samples that correspond correctly to the
 analog
 

Re: [casper] examples using complex inputs

[G Jones]

Several of the MKID systems use I/Q inputs. There's no real trick, they
just go through PFB_FIR real blocks (one for each I and Q) and then into
the classic fft block as the real and imag parts of the input data.

On Fri, Nov 7, 2014 at 1:57 PM, John Ford jf...@nrao.edu wrote:

 Hi all.  Are there any example spectrometers or correlators that use I/Q
 sampling as opposed to the usual real-valued ADCs we generally use
 nowadays?  It seems like some early designs used these.

 We need to build a design that uses an I/Q stream as input, and we'd like
 to get a jump start on it by starting with a working model.

 Thanks!

 John

Re: [casper] wide_band_real fft simulation problem of tut3

[G Jones]

When you are simulating, do you have the fftshift set appropriately? A pure
sine wave will be the worst case for bit growth and overflow, so you'll
want an fftshift of 0x I think.
On Nov 2, 2014 2:11 AM, Wang Jinqing jqw...@shao.ac.cn wrote:

 Hi,

 I can run the tut3.mdl,but I found the simulation result of  wide_band fft
 is not correct. For example I have generate a sine (freq= 1/4pi)wave input
 the KaADC ,I found the polyphase output sine wave is still ok on the scope,
  but after the wide_band_real fft ( after real and image parts seperation)
 and power I even can't find the corresponding spectrum line. There're many
 messy signals on the spectrum. It seems that the fft core not works well in
 simulation. Does someone run into this problem?

 Best Regards.

 Oliver Wang.

Re: [casper] i_poco4_1024ch_v010

[G Jones]

Hi Rolando,
I think that sync period seems OK. Accumulation length is set by the user
typically, but the default is probably fine. The one concern is that number
is  2^32, so be careful that your sync period register is set up to handle
that case. The software registers are 32 bits wide, so it probably will
overflow. In which case you should reduce accumulation length to make sure
that sync period is  2^32. When you do that, you'll also want to use the
appropriate value for the accumulation length register, wherever that is in
your design.

Glenn


On Mon, Aug 4, 2014 at 11:38 AM, Rolando Paz flx...@gmail.com wrote:

 Hi All

 The sync_period is = n * k * LCM (reorder orders) * PFB_taps *  FFT_length
 /  #simultaneous_inputs

 n=100
 k= 1460? (copied from poco)
 LCM(2,2,2,9)=18
 PFB_taps=4
 FFT_length=2048
 #simultaneous_inputs=4

 sync_period= 5382144000

 1) Is this sync_period correct?
 2) k is the Accumulation Length. How do I get this value?
 3) Is it correct the value of LCM (reorders)?

 Now I understand more the design, so more questions arise :-)

 Best Regards

 Rolando Paz

Re: [casper] bitfile

[G Jones]

What happens when you try to startupddump?


On Thu, Jul 10, 2014 at 10:20 AM, Rolando Paz flx...@gmail.com wrote:

 Hi Glenn

 Griffin helped me understand that the file that I should use is called
 download.bit and not the original file that was compiled :-)

 However, now I login via telnet again and I can not start udp dump.

 version
 clkmeasure
 clkreset
 clkphase
 listdev
 read
 write
 readbase
 writebase
 setbase
 regwrite
 regread
 bramwrite
 bramread
 bramdump
 ifconfig
 startudpdump
 endudpdump

 So I think now I am using the correct bitfile, but still missing something
 ...

 Rolando Paz

Re: [casper] bitfile

[G Jones]

I mean wherever you have defined the startudp function. I notice there's
already this line in there:
xil_printf(UDP pcb instantiated\n\r);

If I recall, this message will go to the RS-232 serial port. I suggest
watching the output from that port when you try to send the startudp
command and see if you see any of the expected messages.
You can then add other xil_printf statements to see what part the program
is getting stuck on.

Glenn


On Thu, Jul 10, 2014 at 10:38 AM, Rolando Paz flx...@gmail.com wrote:

 Do I must do this in main.c file?




 2014-07-10 8:30 GMT-06:00 G Jones glenn.calt...@gmail.com:

 Try adding some debug printf type statements to the startudp function to
 see where it might be getting hung up.


 On Thu, Jul 10, 2014 at 10:27 AM, Rolando Paz flx...@gmail.com wrote:

 With Aaron's bitfile the transmission of bram is initialized, I can see
 this from wireshark, but with my bitfile nothing happens ...


 2014-07-10 8:21 GMT-06:00 G Jones glenn.calt...@gmail.com:

 What happens when you try to startupddump?


 On Thu, Jul 10, 2014 at 10:20 AM, Rolando Paz flx...@gmail.com wrote:

 Hi Glenn

 Griffin helped me understand that the file that I should use is called
 download.bit and not the original file that was compiled :-)

 However, now I login via telnet again and I can not start udp dump.

 version
 clkmeasure
 clkreset
 clkphase
 listdev
 read
 write
 readbase
 writebase
 setbase
 regwrite
 regread
 bramwrite
 bramread
 bramdump
 ifconfig
 startudpdump
 endudpdump

 So I think now I am using the correct bitfile, but still missing
 something ...

 Rolando Paz

Re: [casper] bitfile

[G Jones]

Sorry, I'm not sure what you mean. Are you seeing stuff come out the RS-232
port?


On Thu, Jul 10, 2014 at 6:07 PM, Rolando Paz flx...@gmail.com wrote:

 Hi Glenn

 I read the following main.c file from another project:


 https://casper.berkeley.edu/svn/trunk/projects/leuschner_spec/ppc_source/main.c

 The main.c file I'm using is this:


 https://casper.berkeley.edu/svn/trunk/projects/pocketcorrelator/poco-0.1.1/src/main_i4_c2048.c

 And I think this last file was designed for the serial port, as you say
 Glenn :-) what do you think?

 Best Regards

 Rolando Paz












 2014-07-10 8:42 GMT-06:00 G Jones glenn.calt...@gmail.com:

 I mean wherever you have defined the startudp function. I notice there's
 already this line in there:
 xil_printf(UDP pcb instantiated\n\r);

 If I recall, this message will go to the RS-232 serial port. I suggest
 watching the output from that port when you try to send the startudp
 command and see if you see any of the expected messages.
 You can then add other xil_printf statements to see what part the program
 is getting stuck on.

 Glenn


 On Thu, Jul 10, 2014 at 10:38 AM, Rolando Paz flx...@gmail.com wrote:

 Do I must do this in main.c file?




 2014-07-10 8:30 GMT-06:00 G Jones glenn.calt...@gmail.com:

 Try adding some debug printf type statements to the startudp function to
 see where it might be getting hung up.


 On Thu, Jul 10, 2014 at 10:27 AM, Rolando Paz flx...@gmail.com wrote:

 With Aaron's bitfile the transmission of bram is initialized, I can
 see this from wireshark, but with my bitfile nothing happens ...


 2014-07-10 8:21 GMT-06:00 G Jones glenn.calt...@gmail.com:

 What happens when you try to startupddump?


 On Thu, Jul 10, 2014 at 10:20 AM, Rolando Paz flx...@gmail.com
 wrote:

 Hi Glenn

 Griffin helped me understand that the file that I should use is
 called download.bit and not the original file that was compiled :-)

 However, now I login via telnet again and I can not start udp dump.

 version
 clkmeasure
 clkreset
 clkphase
 listdev
 read
 write
 readbase
 writebase
 setbase
 regwrite
 regread
 bramwrite
 bramread
 bramdump
 ifconfig
 startudpdump
 endudpdump

 So I think now I am using the correct bitfile, but still missing
 something ...

 Rolando Paz

Re: [casper] PowerPC C code modified to automate the transmission of the shared BRAM / IBOB

[G Jones]

Hi Rolando,
I think you mentioned that you are able to communicate with the IBOB over
ethernet. Is that correct? Can you read and set registers using the UDP
interface? If so, then the communication is working and the problem is not
the communication itself.

Glenn


On Fri, Jul 4, 2014 at 9:59 AM, Rolando Paz flx...@gmail.com wrote:

 Hi again everyone!

 I do not know if some one still remember this ... :-)  but I will do the
 question:

 I'm trying to modify the PowerPC code which interacts with LWIP in order
 to automate the transmission of the shared BRAM from my correlator, but I
 was unable accomplish it.

 I'm using CMD (WINXP) to do this:

 The new main.c file is located in the following directory:

 C:/i_poco4_1024ch_v007/XPS_iBOB_base/Software/main.c

 Then I run the following commands, inside the following directory:

 Directory:

 C:/i_poco4_1024ch_v007/XPS_iBOB_base/

 Commands:

  xps -nw system.xmp
  run init_bram


 This is the output of run init_bram:

 XPS% run init_bram
 powerpc-eabi-gcc -Os
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/main
 .c /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/tinysh.c
 /cygdrive/c/i
 _poco4_1024ch_v007/XPS_iBOB_base/drivers/core_util.c
 /cygdrive/c/i_poco4_1024ch_
 v007/XPS_iBOB_base/drivers/xps_xsg/clk.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBO
 B_base/drivers/xps_xsg/devices.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/d
 rivers/xps_xsg/memory.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xp
 s_sw_reg/reg.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_lwip/fi
 fo.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_lwip/lwipinit.c /
 cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_lwip/lwiputil.c
 /cygdri
 ve/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_bram/bram.c
 /cygdrive/c/i_poc
 o4_1024ch_v007/XPS_iBOB_base/drivers/core_info.c  -o
 Software/executable.elf \
  -Wl,-T
 -Wl,/cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/LinkerScr
 ipt.lwip -I./ppc405_1/include/  -ISoftware/ -Idrivers/
 -Idrivers/xps_xsg/ -I
 drivers/xps_sw_reg/ -Idrivers/xps_lwip/ -Idrivers/xps_bram/
  -L./ppc405_1/lib/
 \
 -DLWIP_ENABLE -llwip4
 In file included from ./ppc405_1/include/netif/etharp.h:43,
  from ./ppc405_1/include/netif/xemacliteif.h:42,
  from
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/mai
 n.c:24:
 ./ppc405_1/include/lwip/ip.h:125: warning: 'packed' attribute ignored for
 field
 of type 'struct ip_addr'
 ./ppc405_1/include/lwip/ip.h:126: warning: 'packed' attribute ignored for
 field
 of type 'struct ip_addr'
 In file included from ./ppc405_1/include/netif/xemacliteif.h:42,
  from
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/mai
 n.c:24:
 ./ppc405_1/include/netif/etharp.h:50: warning: 'packed' attribute ignored
 for fi
 eld of type 'u8_t[5u]'
 ./ppc405_1/include/netif/etharp.h:56: warning: 'packed' attribute ignored
 for fi
 eld of type 'struct eth_addr'
 ./ppc405_1/include/netif/etharp.h:57: warning: 'packed' attribute ignored
 for fi
 eld of type 'struct eth_addr'
 ./ppc405_1/include/netif/etharp.h:65: warning: 'packed' attribute ignored
 for fi
 eld of type 'struct eth_hdr'
 ./ppc405_1/include/netif/etharp.h:70: warning: 'packed' attribute ignored
 for fi
 eld of type 'struct eth_addr'
 ./ppc405_1/include/netif/etharp.h:71: warning: 'packed' attribute ignored
 for fi
 eld of type 'struct ip_addr'
 ./ppc405_1/include/netif/etharp.h:72: warning: 'packed' attribute ignored
 for fi
 eld of type 'struct eth_addr'
 ./ppc405_1/include/netif/etharp.h:73: warning: 'packed' attribute ignored
 for fi
 eld of type 'struct ip_addr'
 ./ppc405_1/include/netif/etharp.h:79: warning: 'packed' attribute ignored
 for fi
 eld of type 'struct eth_hdr'
 ./ppc405_1/include/netif/etharp.h:80: warning: 'packed' attribute ignored
 for fi
 eld of type 'struct ip_hdr'
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/main.c: In function
 'star
 tudpdump_cmd':
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/main.c:184:
 warning: assi
 gnment makes pointer from integer without a cast
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/main.c: In function
 'main
 ':
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/main.c:416:
 warning: inco
 mpatible implicit declaration of built-in function 'memcpy'
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/main.c:437:
 warning: inco
 mpatible implicit declaration of built-in function 'memcpy'
 In file included from ./ppc405_1/include/netif/etharp.h:43,
  from ./ppc405_1/include/netif/xemacliteif.h:42,
  from
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_
 lwip/lwipinit.c:10:
 ./ppc405_1/include/lwip/ip.h:125: warning: 'packed' attribute ignored for
 field
 of type 'struct ip_addr'
 ./ppc405_1/include/lwip/ip.h:126: warning: 'packed' attribute ignored for
 field
 of type 'struct ip_addr'
 In file included from 

Re: [casper] PowerPC C code modified to automate the transmission of the shared BRAM / IBOB

[G Jones]

Yeah, somehow it looks like the new main.c you are trying to use is not
getting included. Where are you putting the main.c? One thing you can try
is instead of putting your new main.c in there, try just deleting the
main.c that is there and try the run init_bram. If it does not fail, then
that means the main.c you are replacing is not the one it is using...


On Fri, Jul 4, 2014 at 10:31 AM, Rolando Paz flx...@gmail.com wrote:

 Hi Glenn

 Yes, I communicate with the IBOB over ethernet.

 I found what you see in the attached images.

 After running the following commands, with the Aaron bit file programed
 inside the IBOB, the bram transmission was initialized.

 regwrite ctrl_sw 0x03ff
 regwrite sync_gen/period 149504000
 startudpdump

 When I run the same commands with my bit file inside the IBOB, I found
 that the command startudpdump is not there!

 That's why I think I'm doing something wrong, so the main.c does not
 modify the PowerPC code, and hence is not programmed startudpdum.





 2014-07-04 8:04 GMT-06:00 G Jones glenn.calt...@gmail.com:

 Hi Rolando,
 I think you mentioned that you are able to communicate with the IBOB over
 ethernet. Is that correct? Can you read and set registers using the UDP
 interface? If so, then the communication is working and the problem is not
 the communication itself.

 Glenn


 On Fri, Jul 4, 2014 at 9:59 AM, Rolando Paz flx...@gmail.com wrote:

 Hi again everyone!

 I do not know if some one still remember this ... :-)  but I will do the
 question:

 I'm trying to modify the PowerPC code which interacts with LWIP in order
 to automate the transmission of the shared BRAM from my correlator, but I
 was unable accomplish it.

 I'm using CMD (WINXP) to do this:

 The new main.c file is located in the following directory:

 C:/i_poco4_1024ch_v007/XPS_iBOB_base/Software/main.c

 Then I run the following commands, inside the following directory:

 Directory:

 C:/i_poco4_1024ch_v007/XPS_iBOB_base/

 Commands:

  xps -nw system.xmp
  run init_bram


 This is the output of run init_bram:

 XPS% run init_bram
 powerpc-eabi-gcc -Os
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/main
 .c /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/tinysh.c
 /cygdrive/c/i
 _poco4_1024ch_v007/XPS_iBOB_base/drivers/core_util.c
 /cygdrive/c/i_poco4_1024ch_
 v007/XPS_iBOB_base/drivers/xps_xsg/clk.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBO
 B_base/drivers/xps_xsg/devices.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/d
 rivers/xps_xsg/memory.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xp
 s_sw_reg/reg.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_lwip/fi
 fo.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_lwip/lwipinit.c /
 cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_lwip/lwiputil.c
 /cygdri
 ve/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_bram/bram.c
 /cygdrive/c/i_poc
 o4_1024ch_v007/XPS_iBOB_base/drivers/core_info.c  -o
 Software/executable.elf \
  -Wl,-T
 -Wl,/cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/LinkerScr
 ipt.lwip -I./ppc405_1/include/  -ISoftware/ -Idrivers/
 -Idrivers/xps_xsg/ -I
 drivers/xps_sw_reg/ -Idrivers/xps_lwip/ -Idrivers/xps_bram/
  -L./ppc405_1/lib/
 \
 -DLWIP_ENABLE -llwip4
 In file included from ./ppc405_1/include/netif/etharp.h:43,
  from ./ppc405_1/include/netif/xemacliteif.h:42,
  from
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/mai
 n.c:24:
 ./ppc405_1/include/lwip/ip.h:125: warning: 'packed' attribute ignored
 for field
 of type 'struct ip_addr'
 ./ppc405_1/include/lwip/ip.h:126: warning: 'packed' attribute ignored
 for field
 of type 'struct ip_addr'
 In file included from ./ppc405_1/include/netif/xemacliteif.h:42,
  from
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/mai
 n.c:24:
 ./ppc405_1/include/netif/etharp.h:50: warning: 'packed' attribute
 ignored for fi
 eld of type 'u8_t[5u]'
 ./ppc405_1/include/netif/etharp.h:56: warning: 'packed' attribute
 ignored for fi
 eld of type 'struct eth_addr'
 ./ppc405_1/include/netif/etharp.h:57: warning: 'packed' attribute
 ignored for fi
 eld of type 'struct eth_addr'
 ./ppc405_1/include/netif/etharp.h:65: warning: 'packed' attribute
 ignored for fi
 eld of type 'struct eth_hdr'
 ./ppc405_1/include/netif/etharp.h:70: warning: 'packed' attribute
 ignored for fi
 eld of type 'struct eth_addr'
 ./ppc405_1/include/netif/etharp.h:71: warning: 'packed' attribute
 ignored for fi
 eld of type 'struct ip_addr'
 ./ppc405_1/include/netif/etharp.h:72: warning: 'packed' attribute
 ignored for fi
 eld of type 'struct eth_addr'
 ./ppc405_1/include/netif/etharp.h:73: warning: 'packed' attribute
 ignored for fi
 eld of type 'struct ip_addr'
 ./ppc405_1/include/netif/etharp.h:79: warning: 'packed' attribute
 ignored for fi
 eld of type 'struct eth_hdr'
 ./ppc405_1/include/netif/etharp.h:80: warning: 'packed' attribute
 ignored for fi
 eld of type 'struct ip_hdr'
 /cygdrive/c

Re: [casper] PowerPC C code modified to automate the transmission of the shared BRAM / IBOB

[G Jones]

I think that's the wrong place. You want something in the implementation
directory if i recall correctly.
Glenn
On Jul 4, 2014 11:05 AM, Rolando Paz flx...@gmail.com wrote:

 When the design is compiled, several folders are created.
 The XPS_IBOB_base folder is one of them, and inside this folder is created
 the Software folder, and inside this folder is created the main.c file.
 I remove this main.c file created by the compilation, and I copy the new
 main.c in the same directory.

 C:/i_poco4_1024ch_v007/XPS_iBOB_base/Software/main.c

 Thanks Glenn, I will do the test you suggested me.

 Rolando Paz




 2014-07-04 8:39 GMT-06:00 G Jones glenn.calt...@gmail.com:

 Yeah, somehow it looks like the new main.c you are trying to use is not
 getting included. Where are you putting the main.c? One thing you can try
 is instead of putting your new main.c in there, try just deleting the
 main.c that is there and try the run init_bram. If it does not fail, then
 that means the main.c you are replacing is not the one it is using...


 On Fri, Jul 4, 2014 at 10:31 AM, Rolando Paz flx...@gmail.com wrote:

 Hi Glenn

 Yes, I communicate with the IBOB over ethernet.

 I found what you see in the attached images.

 After running the following commands, with the Aaron bit file programed
 inside the IBOB, the bram transmission was initialized.

 regwrite ctrl_sw 0x03ff
 regwrite sync_gen/period 149504000
 startudpdump

 When I run the same commands with my bit file inside the IBOB, I found
 that the command startudpdump is not there!

 That's why I think I'm doing something wrong, so the main.c does not
 modify the PowerPC code, and hence is not programmed startudpdum.





 2014-07-04 8:04 GMT-06:00 G Jones glenn.calt...@gmail.com:

 Hi Rolando,
 I think you mentioned that you are able to communicate with the IBOB
 over ethernet. Is that correct? Can you read and set registers using the
 UDP interface? If so, then the communication is working and the problem is
 not the communication itself.

 Glenn


 On Fri, Jul 4, 2014 at 9:59 AM, Rolando Paz flx...@gmail.com wrote:

 Hi again everyone!

 I do not know if some one still remember this ... :-)  but I will do
 the question:

 I'm trying to modify the PowerPC code which interacts with LWIP in
 order to automate the transmission of the shared BRAM from my correlator,
 but I was unable accomplish it.

 I'm using CMD (WINXP) to do this:

 The new main.c file is located in the following directory:

 C:/i_poco4_1024ch_v007/XPS_iBOB_base/Software/main.c

 Then I run the following commands, inside the following directory:

 Directory:

 C:/i_poco4_1024ch_v007/XPS_iBOB_base/

 Commands:

  xps -nw system.xmp
  run init_bram


 This is the output of run init_bram:

 XPS% run init_bram
 powerpc-eabi-gcc -Os
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/main
 .c /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/tinysh.c
 /cygdrive/c/i
 _poco4_1024ch_v007/XPS_iBOB_base/drivers/core_util.c
 /cygdrive/c/i_poco4_1024ch_
 v007/XPS_iBOB_base/drivers/xps_xsg/clk.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBO
 B_base/drivers/xps_xsg/devices.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/d
 rivers/xps_xsg/memory.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xp
 s_sw_reg/reg.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_lwip/fi
 fo.c
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_lwip/lwipinit.c 
 /
 cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_lwip/lwiputil.c
 /cygdri
 ve/c/i_poco4_1024ch_v007/XPS_iBOB_base/drivers/xps_bram/bram.c
 /cygdrive/c/i_poc
 o4_1024ch_v007/XPS_iBOB_base/drivers/core_info.c  -o
 Software/executable.elf \
  -Wl,-T
 -Wl,/cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/LinkerScr
 ipt.lwip -I./ppc405_1/include/  -ISoftware/ -Idrivers/
 -Idrivers/xps_xsg/ -I
 drivers/xps_sw_reg/ -Idrivers/xps_lwip/ -Idrivers/xps_bram/
  -L./ppc405_1/lib/
 \
 -DLWIP_ENABLE -llwip4
 In file included from ./ppc405_1/include/netif/etharp.h:43,
  from ./ppc405_1/include/netif/xemacliteif.h:42,
  from
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/mai
 n.c:24:
 ./ppc405_1/include/lwip/ip.h:125: warning: 'packed' attribute ignored
 for field
 of type 'struct ip_addr'
 ./ppc405_1/include/lwip/ip.h:126: warning: 'packed' attribute ignored
 for field
 of type 'struct ip_addr'
 In file included from ./ppc405_1/include/netif/xemacliteif.h:42,
  from
 /cygdrive/c/i_poco4_1024ch_v007/XPS_iBOB_base/Software/mai
 n.c:24:
 ./ppc405_1/include/netif/etharp.h:50: warning: 'packed' attribute
 ignored for fi
 eld of type 'u8_t[5u]'
 ./ppc405_1/include/netif/etharp.h:56: warning: 'packed' attribute
 ignored for fi
 eld of type 'struct eth_addr'
 ./ppc405_1/include/netif/etharp.h:57: warning: 'packed' attribute
 ignored for fi
 eld of type 'struct eth_addr'
 ./ppc405_1/include/netif/etharp.h:65: warning: 'packed' attribute
 ignored for fi
 eld of type 'struct eth_hdr'
 ./ppc405_1

Re: [casper] pfb/fft confusion

[G Jones]

You want The PFB to have 2^0 simultaneous inputs, then make one PFB for
each stream.



On Wed, May 28, 2014 at 2:41 PM, Jay Brady jay_br...@live.com wrote:

 Hello all,

 With all of the different pfb/fft blocks, I've gotten a bit confused. Some
 of the terminology used on the wiki is a bit unclear to me (simultaneous
 streams vs simultaneous inputs vs parallel time samples) which has led to
 this confusion

 Anyway, I'm trying to build a spectrometer (a la tutorial 3) for the
 adc16x250, with the adc running 16 channel at 200 Msamp/s (so no demuxing).
 This gives me 16 inputs that are fed into a pfb/fft block combo. I'm
 concerned that I am somehow getting those 16 inputs mixed up in the pfb or
 fft.

 Here are the blocks and parameters I'm using right now:
 pfb_fir_real with size: 2^10, Taps: 4, Simultaneous Inputs: 2^2, and the
 Make Biplex box is not checked.
 fft_biplex_real_4x with size: 2^10 and Simultaneous Inputs 4^1.
 This gives me 4 inputs/outputs on each of the blocks which are just wired
 straight through.


 With this, the fft outputs seem ok-ish. I get a peak at the right
 frequency channel, but the sidelobe behavior is pretty terrible. I get high
 sidelobes that sometimes extend out 20-30 bins on either side of the main
 peak.

 Any advice you can give would be great.

 Jay Brady

Re: [casper] pfb/fft confusion

[G Jones]

Yes, i.e. if you set it to 2^2 then it means the PFB processes x0,x1,x2,x3
on the first FPGA clock, then x4,x5,x6,x7 on the second FPGA clock, etc...


On Wed, May 28, 2014 at 3:15 PM, Jay Brady jay_br...@live.com wrote:


 So does simultaneous inputs refer to simultaneous samples (within one fpga
 clock) of a single physical input channel?

 --
 Date: Wed, 28 May 2014 14:43:24 -0400
 Subject: Re: [casper] pfb/fft confusion
 From: glenn.calt...@gmail.com
 To: jay_br...@live.com
 CC: casper@lists.berkeley.edu


 You want The PFB to have 2^0 simultaneous inputs, then make one PFB for
 each stream.



 On Wed, May 28, 2014 at 2:41 PM, Jay Brady jay_br...@live.com wrote:

 Hello all,

 With all of the different pfb/fft blocks, I've gotten a bit confused. Some
 of the terminology used on the wiki is a bit unclear to me (simultaneous
 streams vs simultaneous inputs vs parallel time samples) which has led to
 this confusion

 Anyway, I'm trying to build a spectrometer (a la tutorial 3) for the
 adc16x250, with the adc running 16 channel at 200 Msamp/s (so no demuxing).
 This gives me 16 inputs that are fed into a pfb/fft block combo. I'm
 concerned that I am somehow getting those 16 inputs mixed up in the pfb or
 fft.

 Here are the blocks and parameters I'm using right now:
 pfb_fir_real with size: 2^10, Taps: 4, Simultaneous Inputs: 2^2, and the
 Make Biplex box is not checked.
 fft_biplex_real_4x with size: 2^10 and Simultaneous Inputs 4^1.
 This gives me 4 inputs/outputs on each of the blocks which are just wired
 straight through.


 With this, the fft outputs seem ok-ish. I get a peak at the right
 frequency channel, but the sidelobe behavior is pretty terrible. I get high
 sidelobes that sometimes extend out 20-30 bins on either side of the main
 peak.

 Any advice you can give would be great.

 Jay Brady

Re: [casper] xst hangs

[G Jones]

Did you increase your matlab java heap? Search the mailing list archives,
sounds like it could be the culprit.

Glenn
On Apr 11, 2014 9:31 PM, Matt Strader mstra...@physics.ucsb.edu wrote:

 Hi all,

 I have a rather large design I'm trying to compile for Roach2.
  Compilation never gets past xst in System Generator, but doesn't give any
 error.  Progress seems to halt while trimming pins, stopping in the middle
 of printing a warning, such as
 WARNING:Xst:1710 - FF/Latch fft_stage_6_.
 Then cpu usage drops to near zero, and it just hangs there.  It never
 takes more than 16% of my RAM, so it's not lagging from lack of memory.

 If I cut a big chunk out of my design, it compiles successfully.

 Any suggestions?

 Thanks,
 Matt Strader
 UCSB Physics Dept.

Re: [casper] Problem writing to DRAM, ROACH 1

[G Jones]

Hi,

I think I ran into similar issues, but I don't remember it being a
consistent failure for a given size, just that large transfers were
somewhat unreliable.
I used code like this:
 def _load_dram_katcp(self,data,tries=2):
while tries  0:
try:
self._pause_dram()
self.r.write_dram(data.tostring())
self._unpause_dram()
return
except Exception, e:
print failure writing to dram, trying again
# print e
tries = tries - 1
raise Exception(Writing to dram failed!)

to help deal with such problems. But then I found I got more speed by
generating the data as a file on the file system (since I was running the
code on the same machine that hosts the ROACH NFS file system, so I could
write the data to e.g. /srv/roach_boot/etch/boffiles/dram.bin) and then use
the linux command dd on the roach to write the data to DRAM. The code looks
like:

def
_load_dram_ssh(self,data,offset_bytes=0,roach_root='/srv/roach_boot/etch',datafile='boffiles/dram.bin'):
offset_blocks = offset_bytes/512 #dd uses blocks of 512 bytes by
default
self._update_bof_pid()
self._pause_dram()
data.tofile(os.path.join(roach_root,datafile))
dram_file = '/proc/%d/hw/ioreg/dram_memory' % self.bof_pid
datafile = '/' + datafile
result = borph_utils.check_output(('ssh root@%s dd seek=%d if=%s
of=%s' % (self.roachip,offset_blocks,datafile,dram_file)),shell=True)
print result
self._unpause_dram()

This seems to work pretty well.

Glenn


On Tue, Apr 8, 2014 at 4:51 PM, Madden, Timothy J. tmad...@aps.anl.govwrote:



 I am using a DRAM block on a ROACH 1.

 I am using python to write data to the dram with corr.

 I create a binary array of zeros like:

 fa.lut_binaryIQ = '\x00\x00\x00\x00\x00\x00.'

 Length of the array is 1048576.

 If I do
 roach.write('dram_memory',fa.lut_binaryIQ)

 It works fine.

 If I double the length of the binary array, where
 len(fa.lut_binaryIQ)=2097152

 Then I do
 roach.write('dram_memory',fa.lut_binaryIQ)

 I get a timeout error
 RuntimeError: Request write timed out after 20 seconds.


 I have tried longer and longer timeouts of 60sec and still no good result.
 I set the timeout with:
 roach = corr.katcp_wrapper.FpgaClient('192.168.0.67', 7147,timeout=60)


 Any ideas? It seems there is a 1MB length limit on my dram.

 Tim

Re: [casper] init_poco.py and poco_rx_i8_c256.py // IBOB Correlator

[G Jones]

Hi Rolando,
My guess is that you are not receiving data packets from the ibob, or if
you are, they are not the right size. Did you use wireshark to see if
packets are coming in and what they look like?
Glenn
On Apr 3, 2014 10:20 PM, Rolando Paz flx...@gmail.com wrote:

 Hi all.

 I run the command initiating transmission of data from the IBOB:
 init_poco.py i8_c256.py

 rolando@rolando-MS-7815:~/ibob/poco011$ init_poco.py i8_c256.config

 Parsing config file i8_c256.config...OK

 Writing override variables... OK

 Connecting to iBOB... OK

 After I run the command: sudo poco_rx_i8_c256.py i8_c256.config, in order
 to obtain data packages in MIRIAD file, but the following error occurs:

 rolando@rolando-MS-7815:~/ibob/poco011$ sudo poco_rx_i8_c256.py
 i8_c256.config

 Parsing config file i8_c256.config...OK
 Listening on port 7
 Expecting integration sizes of 18432 vectors, or 73728 bytes
 C2M Parameters:
 N Antennas: 8
  Bandwidth: 0.20 GHz
 SDF: 0.000781 GHz
  Int Time: 0.747520 s
 Array location:  ['38:25:59.24', '-79:51:02.1']
 Recording Bandpass to file... OK
 Starting file: zen.uv.tmp
 Beginning RX thread...
 Expecting total dump size from each x engine: 65536 bytes
 ERR: Buffer is too small for header unpack
 ERR: could not unpack header
 Exception in thread Thread-1:
 Traceback (most recent call last):
   File /usr/lib/python2.7/threading.py, line 551, in __bootstrap_inner
 self.run()
   File /usr/lib/python2.7/threading.py, line 504, in run
 self.__target(*self.__args, **self.__kwargs)
   File /usr/local/bin/poco_rx_i8_c256.py, line 243, in _process_packets
 last_offset = p['offset']
 TypeError: 'NoneType' object has no attribute '__getitem__'

 Any suggestions?

 Is it a PC problem or script problem?

 Best Regards

 Rolando Paz

Re: [casper] init_poco.py and poco_rx_i8_c256.py // IBOB Correlator

[G Jones]

OK, that looks like all of the transactions to set up the registers etc.
Presumably the power PC code should be set up to send out data packets as
well. Again, I'm not familiar with this poco so maybe someone else can
chime in.
Glenn


On Fri, Apr 4, 2014 at 9:30 AM, Rolando Paz flx...@gmail.com wrote:

 Hi Glenn

 Indeed, I used wireshark. When I run Init_poco.py i8_c256.config, I get
 what you see in the attached image.

 But only that is observed.

 Rolando Paz



 2014-04-04 1:12 GMT-06:00 G Jones glenn.calt...@gmail.com:

 Hi Rolando,
 My guess is that you are not receiving data packets from the ibob, or if
 you are, they are not the right size. Did you use wireshark to see if
 packets are coming in and what they look like?
 Glenn
 On Apr 3, 2014 10:20 PM, Rolando Paz flx...@gmail.com wrote:

 Hi all.

 I run the command initiating transmission of data from the IBOB:
 init_poco.py i8_c256.py

 rolando@rolando-MS-7815:~/ibob/poco011$ init_poco.py i8_c256.config

 Parsing config file i8_c256.config...OK

 Writing override variables... OK

 Connecting to iBOB... OK

 After I run the command: sudo poco_rx_i8_c256.py i8_c256.config, in
 order to obtain data packages in MIRIAD file, but the following error
 occurs:

 rolando@rolando-MS-7815:~/ibob/poco011$ sudo poco_rx_i8_c256.py
 i8_c256.config

 Parsing config file i8_c256.config...OK
 Listening on port 7
 Expecting integration sizes of 18432 vectors, or 73728 bytes
 C2M Parameters:
 N Antennas: 8
  Bandwidth: 0.20 GHz
 SDF: 0.000781 GHz
  Int Time: 0.747520 s
 Array location:  ['38:25:59.24', '-79:51:02.1']
 Recording Bandpass to file... OK
 Starting file: zen.uv.tmp
 Beginning RX thread...
 Expecting total dump size from each x engine: 65536 bytes
 ERR: Buffer is too small for header unpack
 ERR: could not unpack header
 Exception in thread Thread-1:
 Traceback (most recent call last):
   File /usr/lib/python2.7/threading.py, line 551, in __bootstrap_inner
 self.run()
   File /usr/lib/python2.7/threading.py, line 504, in run
 self.__target(*self.__args, **self.__kwargs)
   File /usr/local/bin/poco_rx_i8_c256.py, line 243, in _process_packets
 last_offset = p['offset']
 TypeError: 'NoneType' object has no attribute '__getitem__'

 Any suggestions?

 Is it a PC problem or script problem?

 Best Regards

 Rolando Paz

Re: [casper] Casper Workshop June 9 to June 13, 2014, Berkeley

[G Jones]

Maybe this would be a good year to try and get together a critical mass of
people interested in CASPER based kinetic inductance detector (M)KID
readout systems at the workshop.

Glenn


On Tue, Mar 25, 2014 at 3:33 PM, Dan Werthimer d...@ssl.berkeley.eduwrote:



 Dear CASPER Collaborators and Colleagues Interested in DIgital
 Instrumentation,


 We hope you can attend this year's CASPER WORKSHOP


 WHERE:University of California,  Berkeley
  in the Banatao Auditorium, Sutardja Dai Hall


 WHEN:  Monday June 9, 2014  9:00 AM through Friday June 13,  1:00 PM


 ABSTRACTS and REGISTRATION due April 29  (we'll send around more info)


 COST:$125 for students,$250 for everyone else


 WHAT:
 Talks in the morning
 afternoon:  labs, tutorials, working groups and free discussion
 labs with casper hardware and software will be in the radio astronomy
 lab, evans hall
 working groups will likely include:
 correlators and beamformers, spectrometers, pulsar machines,
 next gen tools and libraries, next gen hardware and architectures


 LETTER of INVITATION
 if you'd like a letter of invitation for visa or other purposes,
 please contact matt lebofsky, ma...@ssl.berkeley.edu and
 please cc me


 hoping you can join us,

 dan and the berkeley casper group









 On Fri, Jan 17, 2014 at 11:56 AM, Dan Werthimer d...@ssl.berkeley.eduwrote:





   Dear Casper Collaborators,


 We hope you can attend this year's Casper Worshop

   in Berkeley, California

 June 9 throuh June 13, 2014




 We'll have more information later about registration,
 travel, abstracts, etc, but for now, please reserve these dates.


 Hoping you can participate,


 Dan and the Scientific and Local Organizing Committees

Re: [casper] Telnet IBOB

[G Jones]

Is this with the udp modification? If i recall that disables the telnet
interface. Everything can still be accessed by the udp protocol.

Glenn
On Mar 15, 2014 7:20 PM, Rolando Paz flx...@gmail.com wrote:

 Hi all.

 I have trouble connecting IBOB  with TELNET.

 The IBOB IP address is: 169.254.49.32
 The PC IP address is : 169.254.49.13

 When I do a ping 169.254.49.32, I get response from IBOB, but when i do
 telnet 169.254.49.32, arise this error:

 Trying 169.254.49.32
 telnet: Unable to connect to remote host: Connection refused

 I'm using ubuntu 13.04.

 I also have a winxp virtual machine inside ubuntu 13.04, and when i use
 Hyper Terminal (com1), I have no problem to access the IBOB.

 Someone have any advice?

 Best Regards

 Rolando Paz

Re: [casper] Telnet IBOB

[G Jones]

Yeah, with the udp mod the ibob only communicates by udp on port 7 but your
initpoco script is trying to talk by telnet on port 23 so you need to edit
initpoco to use a udp socket on port 7 and the command format is also
slightly different i think.
On Mar 15, 2014 8:00 PM, Rolando Paz flx...@gmail.com wrote:

 Ok, thank you.

 I think that, that means I have recompiled the bit file, now with port 7?

 Rolando Paz


 2014-03-15 17:48 GMT-06:00 G Jones glenn.calt...@gmail.com:

 Sorry, what I mean is you need to edit your init_poco.py script and make
 it use the udp protocol on port 7 instead of telnet/tcp on port 23. It has
 nothing to do with your python version.
  On Mar 15, 2014 7:46 PM, Rolando Paz flx...@gmail.com wrote:

 I'll update the version of python I am using. Thanks Glenn.

 I am now using port 23. There will be problems with this port?

 Rolando Paz


 2014-03-15 17:41 GMT-06:00 Louis Dartez louisdar...@gmail.com:

 Does it matter what port you use? Have you tried using 7147?

 L
  Louis P. Dartez
  Graduate Research Assistant
  Center for Advanced Radio Astronomy
  University of Texas @ Brownsville

 On Mar 15, 2014, at 6:20 PM, Rolando Paz flx...@gmail.com wrote:

  Hi all.
 
  I have trouble connecting IBOB  with TELNET.
 
  The IBOB IP address is: 169.254.49.32
  The PC IP address is : 169.254.49.13
 
  When I do a ping 169.254.49.32, I get response from IBOB, but when
 i do telnet 169.254.49.32, arise this error:
 
  Trying 169.254.49.32
  telnet: Unable to connect to remote host: Connection refused
 
  I'm using ubuntu 13.04.
 
  I also have a winxp virtual machine inside ubuntu 13.04, and when i
 use Hyper Terminal (com1), I have no problem to access the IBOB.
 
  Someone have any advice?
 
  Best Regards
 
  Rolando Paz

Re: [casper] IP address // IBOB

[G Jones]

Hi Rolando,
Yes, the IP configuration is done in lwipinit.c which I think is part of
the modification in the UDP patch. You can modify it there to whatever you
like.

Glenn


On Tue, Mar 11, 2014 at 12:16 PM, Rolando Paz flx...@gmail.com wrote:

 Hi all again.

 I'm trying to understand why when I set the bit file to the FPGA IBOB,
 change the IBOB IP address 169.254.177.32 to 192.168.49.32, port 7?

 I updated my libraries with
 https://casper.berkeley.edu/wiki/images/6/60/6q05d3bE_udp_patch.tar.gz

 Then I compiled the new design. I got the bit file to use UDP.

 After programming the FPGA with the new bit file happens the IP address
 change.

 Is this normal behavior?

 Best Regards

 Rolando Paz

Re: [casper] IP address // IBOB

[G Jones]

That char ip[4] ={192,168,0,0} sets the top bits of the IP address. If you
look further down in the code, you'll see how fullmac (the MAC hardware
address) is set from the I/O pins, and then ip[3] is set from this too. You
can change this however you want.


On Tue, Mar 11, 2014 at 1:32 PM, Rolando Paz flx...@gmail.com wrote:

 Hi Glenn

 lwipinit.c has the shown in the image lwipinit_c.png

 You can tell me what I should change in lwipinit.c to correct the IP
 address and port?

 Best Regards

 Rolando Paz




 2014-03-11 10:44 GMT-06:00 G Jones glenn.calt...@gmail.com:

 Hi Rolando,
 Yes, the IP configuration is done in lwipinit.c which I think is part of
 the modification in the UDP patch. You can modify it there to whatever you
 like.

 Glenn


 On Tue, Mar 11, 2014 at 12:16 PM, Rolando Paz flx...@gmail.com wrote:

 Hi all again.

 I'm trying to understand why when I set the bit file to the FPGA IBOB,
 change the IBOB IP address 169.254.177.32 to 192.168.49.32, port 7?

 I updated my libraries with
 https://casper.berkeley.edu/wiki/images/6/60/6q05d3bE_udp_patch.tar.gz

 Then I compiled the new design. I got the bit file to use UDP.

 After programming the FPGA with the new bit file happens the IP address
 change.

 Is this normal behavior?

 Best Regards

 Rolando Paz

Re: [casper] ROACH 1 DRAM

[G Jones]

Hi Marc,
Can you expand on this a bit. Are you saying that I should set the top bits
of the DRAM address in the FPGA fabric and that will then affect the 256 MB
portion of the DRAM that is accessed by the PPC, which is then broken up
into the 64 MB chunks described in the block documentation and accessed
with the dram_controller register? That seems counter-intuitive.

Jason, I looked at the read_dram and write_dram functions, and that's
basically the way my code works. I was hoping to see some secret extra
register setting I was missing to explain the behavior I'm seeing.

Thanks again for the input on this problem. Hopefully I'll figure it out
eventually.
Glenn


On Tue, Feb 25, 2014 at 2:43 AM, G Jones glenn.calt...@gmail.com wrote:

 Hi Marc,
 Thanks for the reply. I would have expected that selecting the 64 MB chunk
 with the dram_controller register as described in the DRAM block
 documentation on the wiki would get around any such PPC address space
 limitation. Is that not the case?

 Glenn
 On Feb 25, 2014 2:30 AM, Marc Welz m...@ska.ac.za wrote:

 On Mon, Feb 24, 2014 at 7:57 PM, G Jones glenn.calt...@gmail.com wrote:
  Hi,
  Sorry to repost this. Just curious if anyone has experience using more
 than
  256 MB of FPGA DRAM on the ROACH, in particular through the PPC
 interface.

 The PowerPC's virtual memory subsystem maps things in 256Mb
 regions/segments,
 and only one is used to access the FPGA(*) - so you will probably have
 to implement
 some sort of windowing/base+offset scheme.

 (The address space of the PowerPC is pretty constrained)

 regards

 marc

Re: [casper] ROACH 1 DRAM

[G Jones]

I'm not 100% sure, as I don't write from the fabric: I load using the PPC
interface and then playback from the fabric.
I may have found an addressing problem in my design; I'm rebuilding now to
check it and will report back.


On Wed, Feb 26, 2014 at 10:17 AM, Jason Manley jman...@ska.ac.za wrote:

 Corr does this in 1MB chunks for this reason.

 I suspect a problem in the controller. Glenn, can you access over 256MB
 from the fabric?

 Jason



 On 26 Feb 2014, at 17:13, Marc Welz m...@ska.ac.za wrote:

  On Tue, Feb 25, 2014 at 7:43 AM, G Jones glenn.calt...@gmail.com
 wrote:
  Hi Marc,
  Thanks for the reply. I would have expected that selecting the 64 MB
 chunk
  with the dram_controller register as described in the DRAM block
  documentation on the wiki would get around any such PPC address space
  limitation. Is that not the case?
 
  I think that should indeed be the case - I had forgotten that the
 base+offset
  scheme had already been implemented quite some time ago.
 
  A note though: On the other side of the FPGA, there isn't that much
  memory to go around either - so where possibly try and send it out (or
  process it)
  in smaller pieces
 
  regards
 
  marc
 

Re: [casper] ROACH 1 DRAM

[G Jones]

Hi,
Sorry to repost this. Just curious if anyone has experience using more than
256 MB of FPGA DRAM on the ROACH, in particular through the PPC interface.

Thanks,
Glenn


On Wed, Feb 12, 2014 at 12:44 PM, G Jones glenn.calt...@gmail.com wrote:

 Hi,
 I'm using the ROACH 1 DRAM for a lookup table for waveform generation with
 the DAC. Everything has been working well and as I expected, until I tried
 to use more than 256 MB. It looks like the ROACH has a single sided 1 GB
 DRAM module in the FPGA DRAM slot, but I don't have the exact part number
 (it came as shipped from Mo). I figured I might only be able to use 512 MB
 because of the caveat listed on the DRAM wiki page:
 Many ROACHs have been shipped with 1 GB dual rank DIMMs by default. The
 current DRAM controller is not able to handle multiple ranks, so when a
 dual-rank DIMM is installed on the board, only half the memory is
 available. In order to use the full 1 GB, a single rank DIMM is needed, or
 in principle a dual rank 2 GB module.

 But I was surprised to have issues passed 256 MB. Has anyone seen anything
 like this before? Is it a known issue?

 Thanks,
 Glenn

Re: [casper] ROACH 1 DRAM

[G Jones]

Hi Marc,
Thanks for the reply. I would have expected that selecting the 64 MB chunk
with the dram_controller register as described in the DRAM block
documentation on the wiki would get around any such PPC address space
limitation. Is that not the case?

Glenn
On Feb 25, 2014 2:30 AM, Marc Welz m...@ska.ac.za wrote:

 On Mon, Feb 24, 2014 at 7:57 PM, G Jones glenn.calt...@gmail.com wrote:
  Hi,
  Sorry to repost this. Just curious if anyone has experience using more
 than
  256 MB of FPGA DRAM on the ROACH, in particular through the PPC
 interface.

 The PowerPC's virtual memory subsystem maps things in 256Mb
 regions/segments,
 and only one is used to access the FPGA(*) - so you will probably have
 to implement
 some sort of windowing/base+offset scheme.

 (The address space of the PowerPC is pretty constrained)

 regards

 marc

Re: [casper] ROACH-2 USB Communication Dead?

[G Jones]

Be sure you try to press enter a few times... the ROACH won't say anything
in general except during bootup since it will be sitting there with a login
prompt

also I think I remember the default port being the second or third one of
the 4 that show up when you plug in the usb cable...


On Wed, Feb 12, 2014 at 3:58 PM, Richard Black rallenbl...@gmail.comwrote:

 Jack and all,

 Well, using the *right* connector on the ROACH-2 board (USB-B), I'm able
 to get the USB-OK LED to light up. However, I still see nothing in the
 minicom terminal (using RHEL 6.5). I earlier read on the mailing list that
 there were some rule issues with serial communications with RHEL, but it
 didn't seem to be completely resolved.

 I've also noticed something peculiar. If I power-up the ROACH-2 while
 having minicom open on the PC, the ROACH-2 fault LED lights up and does not
 turn off until I terminate minicom.  Any idea why this might be happening?

 Thanks all,
 Richard

 On Wed, Feb 12, 2014 at 1:37 PM, Jack Hickish jackhick...@gmail.comwrote:

 Yeah, it's not great naming. host and slave or something like that
 would probably have been better. I'm pretty sure FTDI is just the
 brand name for the chip which provides USB to rs232. I didn't know
 this, but it seems it stands for future technology devices
 international :)

 On 12 February 2014 20:32, Richard Black rallenbl...@gmail.com wrote:
  Jack,
 
  I've been connecting to the USB-A (the one that is named PPC USB). I
 assumed
  that that was the correct port since the PPC was booting up.
 
  I'll try again with the FTDI connector.
 
  For the sake of curiosity, what does FTDI stand for? I haven't been
 able to
  find any documentation on the wiki about what it means.
 
  Thanks again,
 
  Richard Black

 
 
  On Wed, Feb 12, 2014 at 1:28 PM, Jack Hickish jackhick...@gmail.com
 wrote:
 
  Hi Richard,
 
  There are two USB connectors on the board -- the USB B one is the one
  which will show up to a PC as a serial device. The USB A one for
  adding slave devices to the power pc (eg booting a file system from
  usb) -- are you connecting to the right one?
 
  Cheers,
  Jack
 
  On 12 February 2014 20:20, Richard Black rallenbl...@gmail.com
 wrote:
   Hi all,
  
   We've been trying to get the serial link between the ROACH-2 and a
 PC,
   and
   we haven't had any success at all.
  
   These are the cable configurations we've tried:
  
   1. USB-A Male (ROACH)/USB-A Male (PC)
   2. USB-A Male (ROACH)/USB-Serial Adapter/DB9 Female (PC)
   3. RS232 Pin Headers on-board/DB9 Male Connector/DB9 Female (PC)
  
   Unfortunately, none of these register any activity on the PC. These
   configurations have been tested on the following operating systems:
  
   1. RHEL 6.5
   2. Ubuntu 11.04
  
   When I connect the cables up and run dmesg, I see no activity. I've
   tried
   listening on ttyS#, ttyUSB# for anything and nothing happens in my
   minicom
   terminal.
  
   Also, our USB-Serial Adapter has a status LED to indicate that it is
   powered
   for conversion, but the LED does not light when connected to the
   ROACH-2.
   This makes me suspicious that the USB connector on the ROACH-2 is not
   functioning.
  
   Has anybody else had a problem with this, or do we unfortunately
 have a
   couple of faulty ROACH-2 boards?
  
   Thanks guys,
   Richard Black
 
 

Re: [casper] Hi // LWIP

[G Jones]

Hi Rolando,
The LWIP core requires the opb_ethernetlite IP core as indicated. You need
to request a license for this from Xilinx.

Glenn


On Mon, Dec 30, 2013 at 4:45 PM, Rolando Paz flx...@gmail.com wrote:

 Hi Glenn

 I drop the LWIP yellow block in my design and then I try to compile, but
 I get the following error:

 Performing Clock DRCs...

 INFO:coreutil - No license for component opb_ethernetlite_v1 found. You
 may
use the customization GUI for this component but you will not be able
 to
generate any implementation or simulation files.

For license installation help, please visit:
www.xilinx.com/ipcenter/ip_license/ip_licensing_help.htm

For ordering information, please refer to the product page for this
 component
on: www.xilinx.com FLEXlm Error: No such feature exists. (-5,21)
 ERROR:MDT - IPNAME:opb_ethernetlite
INSTANCE:spec_256_ibob_quadc_ibob_lwip_ethlite -
C:\specibob\spec_256_ibob_quadc\XPS_iBOB_base\system.mhs line 331 -
 invalid
license or no license found!
 ERROR:MDT - platgen failed with errors!
 make: *** [implementation/system.bmm] Error 2
 ERROR:MDT - Error while running make -f system.make init_bram
 No changes to be saved in MSS file
 Saved project XMP file
 Error using == gen_xps_files at 680
 Programation files generation failed, EDK compilation probably also failed.

 What do you think?

 Best Regards

 Rolando Paz





 2013/12/30 G Jones glenn.calt...@gmail.com

 Hi Rolando,
 You just need to drop the LWIP yellow block in your design and it will
 automatically allow you to talk to the iBOB tiny shell interface over the
 ethernet port. There is also an option for faster UDP communications, which
 might have become the default at some point.. it's been a while since I've
 worked with this. Let me know if you need more information. I think a fair
 bit is documented somewhere on the CASPER wiki.

 Glenn


 On Mon, Dec 30, 2013 at 4:34 PM, Rolando Paz flx...@gmail.com wrote:

 I understand that LWIP block allows the use of Ethernet port on a IBOB.
 But I do not know how to activate this block to compile. Can anyone explain
 me?

 Best Regards


 Rolando Paz

Re: [casper] Caltech's gtkWaveCapture depreciated on Xilinx 14.5

[G Jones]

Hi Antony,
I made  this a very long time ago and haven't maintained it, unfortunately.
I now use the built in WaveScope which is nice. The only problem with it is
that it tries to expose ALL signals in your design which can overwhelm it
when debugging something like the FFT. In those cases, I make a smaller
design to debug.

Glenn


On Mon, Dec 23, 2013 at 6:27 AM, Antony Chan csc...@eee.hku.hk wrote:

 Hi all,

 I would like to analyze the simulation results with Caltech's
 GtkWaveCapture Toolbox. But I got multiple S-function xldeprecated
 Block error:

 ===
 Error reported by S-function 'xldeprecated' in
 'sample/Constant/Const/Gateway Out**':
 This model is out of date.Please run xlUpdateModel('sample') to update it.
 ===

 Does anybody know whether this toolbox is still managed for Matlab
 2012a+Xilinx 14.5?

 Here's the steps to reproduce the result:

 1. Setup casper toolbox by following this link:

 https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.5_and_Matlab_2012b

 2. Download and unzip gtkWave_lib from here:
 https://casper.berkeley.edu/wiki/GtkWaveCapture

 3. Open sample.mdl and click start simulation.

 I am using Ubuntu 12.04 64bit as suggested in step 1.

 Thanks in advance,
 Antony

 --
 Chan Chi Shing, Antony
 PhD Student
 Dept. of Electric  Electronic Engineering
 The University of Hong Kong
 csc...@eee.hku.hk

Re: [casper] On the PFB block- a useful feature that we should have

[G Jones]

I think the 'sinc bandwidth' feature you mention already exists; it's the
Bin Width Scaling (normal=1) field, at least in the slightly outdated
version of the libraries I'm using.


On Fri, Dec 13, 2013 at 5:37 PM, Madden, Timothy J. tmad...@aps.anl.govwrote:



 Folks

 I have a feature request for the PFB block, which should be easy to
 implement, as it is only a matlab gui and script change, and not a hardware
 change.


 The feature I request is to add one more field to the PFB block GUI
 telling the bandwidth of the sinc function. The sinc bandwidth is probably
 set by the FFT length field. We could have something like sinc bandwidth
 field, and put in a floating point number like 0.5 for 1/2 the bandwidth
 (sinc is twice as fat), or 1.0 (sinc in default mode for normal PFB
 operation).  The only difference would be the values of the stored
 coefficients, and no real hard ware changes would be needed.

 Read further to see why I am requesting this. It will allow me to reduce
 my FPGA usage by 50%.


 In reading out MKID's it is common to see a design like the following:

 1) divide incoming signal into two versions, one of them is delayed by N/2
 samples, where N is FFT length.
 2) We have TWO PFB blocks and two FFT blocks, one for the raw signal, and
 one for the delayed signal.

 The reason we must do this is because of the Nyquist theorm. The FFT can
 be run every N samples. The bandwidth of each bin is 2pi/N. To sample each
 bin in time and retain all the information without aliasing, we must run
 the FFT every N/2 samples. This is why we must use two PFBs, a long delay
 line, and two FFT's.
 The result is that for a ROACH 1 board, the FPGA is filled up and hard to
 compile and meet timing specs.

 I have an idea to cut the FPGA usage in half.

 1. We alter the PFB so the internal sinc function is stretched out to have
 the bandwidth of 1/2 bin. Then the windowing function has the bandwindth of
 1/2 bin.
 2. We use only a single FFT and single PFB, and no delay line, and we
 sample each bin every N samples. Because the bandwidth of data in the bin
 is only 2pi/2N, instead of 2pi/N, we do not violate the Nyquist Criterion.


 One may say that we are now no longer sampling the entire bandwidth of the
 spectrum. That is true. If a MKID resonator falls right on a bin edge, then
 one could guess that the system will not see it because it is outside of
 1/2 bin bandwidth. The answer to this is that it will still work.  Because
 the windowing function is modulated by the MKID stimulus signal, which
 should be at resonator center, the 1/2 bin bandwidth captured by the FFT
 will always be centered around the MKID resonator.
 IN this way, even if the resonance is far off the FFT bin center, we still
 see it as long as we stimulate it with the correct frequency. Thinking in
 terms of filter banks, by reducing the bandwidth of the sinc function in
 the PFB block, we reduce the bandwidth of each filter in the bank, and
 allow for slower sampling of each band. But each filter in the bank will
 still be centered around our resonator frequencies.


 Does this make sense or am I crazy?


 Tim Madden

[casper] Library must be saved before creating new library links

[G Jones]

Hi,
When I try to update the FFT (ska-sa F505ED55C8) I'm getting an error
in fft_wideband_real/fft_direct/butterfly0_0/twiddle/coeff_gen:
Initialization commands cannot be evaluated. -- Library must be saved
before creating new library links

This is a new one to me. Any ideas what it means? The libraries are
all saved (I haven't even opened them). The model has been saved too.

Thanks,
Glenn

Re: [casper] Simple clk divider

[G Jones]

Usually people just slice the bit you want off a counter. To select
the bit using a software register, just use the software register as
the select for a mux. Or use the software register as a bit mask and
AND it with the counter, then use the output of a relational == 0 as
your divided counter.

On Wed, Nov 13, 2013 at 5:38 PM, Ross Williamson
rwilliam...@astro.caltech.edu wrote:
 Hi All,

 I suspect this is really simple but I just cannot get this to work in
 simulink.  I would like to divide the sys_clk by a factor set by a
 software register.  To do this in VHDL is very simple - You setup a
 counter and invert the output when it reaches half of the required clk
 divide - the counter is then reset.

 The problem is trying to draw the simulink equivalent. The counter and
 relational are fairly simple but you need to be able to assign an
 initial value to the not gate but I cannot seem to be able to do this.

 What is the obvious thing that I'm missing here?

 Ross

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

[casper] Increasing MATLAB Java heap size reduces stalled XSG builds

[G Jones]

Hi,
I was having issues with complex ROACH 2 designs stalling out during
the XSG synthesis phase of the toolflow, where the machine would sit
there for days and not make any progress. Mark Wagner suggested I
increase the Java Heap Size, which I did, and knock on wood, things
seem to be working much better.

To do this, open Matlab preferences and in the list on the left below
the General heading is Java Heap Memory. The slider defaulted to about
160 MB on this particular machine. I bumped it up to 4 GB (since the
machine has 32 GB of ram), and the performance seems much better.

Just passing this along in case it helps anyone else.

Glenn

Re: [casper] real sampled fft block for 2 inputs per fpga clock

[G Jones]

 half as 
 many outputs as inputs.  Because of this, each output will either multiplex 
 the spectra of two inputs or have half the demux factor of the input(s), 
 depending on which real FFT block you're using.

 Hope this helps,
 Dave

 On Nov 3, 2013, at 10:37 AM, Louis Dartez wrote:

 Hello Glenn,

 Thanks for this; I think I’m getting closer to understanding. I’m 
 shooting for an FFT implementation that gives me 2^11 FFT bins/channels 
 for each polarization (FFT size = 2^12).

 I’ve written my replies below:

 On Nov 3, 2013, at 4:48 AM, G Jones glenn.calt...@gmail.com wrote:
 Hi Louis,
 Replying to the list for the benefit of others.

 You have the right idea. The biplex real 2x block uses the basic biplex 
 core to process two real signal streams or polzns simultaneously with two 
 samples per stream per clock. In theory the top two inputs are for one 
 stream and the result comes out the top output.


 Something that’s confused me is that there is no way to explicitly tell 
 the fft_biplex_2x block how many individual “streams/polarizations” I want 
 to process like there is in the fft_wideband_real block.
 fft_wideband_pars.png
 fft_2x_pars.png
 Two important notes:
 For a long time, there was an error in this block, which may likely still 
 be there where the inputs are mislabeled and a bit scrambled. This may 
 have been fixed, but to be sure, look under the block. The two samples 
 from a stream should be joined in an ri_to_c block. The error was that 
 the streams were crossed so that one sample from each stream was 
 incorrectly combined in the ri_to_c block. I am using this broken version 
 just by ignoring the port labels and connecting the streams based on what 
 the ri_to_c blocks are connected to. Hope that makes sense.


 Yes, I think I get this; it may have since been fixed. I’ve attached an 
 image of the internals of the FFT block along with a possible 
 implementation scheme below:
 fft_biplex_2x_attempt.png
 fft_2x_under_mask.png
 It would seem from the block internals that the samples that belong to the 
 two individual polarizations are (pol0_in, pol1_in) and (pol2_in,pol3_in), 
 respectively. Should I ignore the output port names (pol02_out and 
 pol13_out) and assume that the first (pol02_out) one is fft_0 (serving bin 
 0, then bin 1, then  bin 2…up to bin 2047) and the second fft_1?

 Secondly, I've gotten confused by the number of stages/ length of fft 
 setting for this block a few times. The length is the number of stages 
 and the number of output frequency channels, but the length of the fft 
 (needed by the pfb_fir block, for example) is twice this (the number of 
 real samples in each fft).



 In the parameters for this block (image attached below) I set the size of 
 the FFT to be 2^12 (4096) because I want 2^11 (2048) actual FFT bins 
 across the spectrum. In the version that I have there is no input for 
 telling the FFT block how many stages there should be (opening it up I saw 
 12 individual “fft_stage” blocks).
 fft_2x_pars.png
 From the CASPER wiki:
 Screen Shot 2013-11-03 at 10.26.55 AM.png


 My design will sport two dual input ADCs that output 2 real samples per 
 SMA input each FPGA clock; this a total of 8 real sampled values each 
 clock / 4 polarizations. In your opinion would it be better to simply 
 change the Number of simultaneous inputs parameter to 4*2 (instead of 4*1) 
 to accommodate for the extra two polarizations or should I just use 
 another block entirely?
 fft_biplex_2x_8inputs.png

 Thanks for all the help!
 Louis
 Hope this clarifies things,
 Glenn

 On Nov 2, 2013 11:49 PM, Louis Dartez louisdar...@gmail.com wrote:
 Hello Glenn,

Thanks for the quick reply! I’m a bit confused as how this block 
 works. I’m not quite sure what to make of the following statement from 
 the casper wiki: Real inputs 0 and 2 share one output port (with the data 
 for 0 coming first, then the data for 2), likewise for inputs 1 and 3, 
 and so on.

 Which inputs/outputs correspond to which “stream” or “polarization”? Is 
 the implementation in my attached image close?

 Thanks,
 L
 On Nov 2, 2013, at 8:06 PM, G Jones glenn.calt...@gmail.com wrote:

 The biplex_real_2x is what you want, and it will do two 'polarizations' 
 at a time.

 On Nov 2, 2013 10:56 PM, Louis Dartez louisdar...@gmail.com wrote:
 Hello Mark, Glenn, et al.,


   Does anyone know of any CASPER FFT block that will take as inputs two 
 real sampled values (per ADC input) and output a single complex-valued 
 frequency bin per FPGA clock? The three FFT blocks that I’ve found on 
 the CASPER block documentation and the latest mlib library (wideband 
 real, biplex real 4x, and the biplex real 2x)  all accept real sampled 
 values but require a minimum of 4 simultaneous values per FPGA clock per 
 ADC input. I could really use an FFT block (and a corresponding 
 polyphase FIR block) that will accept only two real sampled values for 
 each of a total of four ADC inputs and spit out

Re: [casper] real sampled fft block for 2 inputs per fpga clock

[G Jones]

The biplex_real_2x is what you want, and it will do two 'polarizations' at
a time.
On Nov 2, 2013 10:56 PM, Louis Dartez louisdar...@gmail.com wrote:

 Hello Mark, Glenn, et al.,


 Does anyone know of any CASPER FFT block that will take as inputs two real
 sampled values (per ADC input) and output a single complex-valued frequency
 bin per FPGA clock? The three FFT blocks that I’ve found on the CASPER
 block documentation and the latest mlib library (wideband 
 realhttps://casper.berkeley.edu/wiki/Fft_wideband_real
 , biplex real 4x https://casper.berkeley.edu/wiki/Fft_biplex_real_4x,
 and the biplex real 2xhttps://casper.berkeley.edu/wiki/Fft_biplex_real_2x)
 all accept real sampled values but require a minimum of 4 simultaneous
 values per FPGA clock per ADC input. I could really use an FFT block (and a
 corresponding polyphase FIR block) that will accept only two real sampled
 values for each of a total of four ADC inputs and spit out a single complex
 FFT bin (per stream) per FPGA clock.

 Can someone point me in the right direction here?

 Thanks!

 L



 Louis P. Dartez

 Graduate Student

 Center for Advanced Radio Astronomy

 University of Texas @ Brownsville

Re: [casper] Ten Gigabit Ethernet Pcores

[G Jones]

Is there a compelling reason to remove it? If I recall, this version
relies on the non-free Xilinx TGE core underneath. It uses a bit more
resources, but is also much more forgiving about spacing between
packets etc. I found it nice to use in the past, though I have
switched over to the new core for new designs.
Glenn

On Tue, Oct 29, 2013 at 10:00 AM, Wesley New wes...@ska.ac.za wrote:
 Hi all,

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


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

Re: [casper] Problem with fi and test suite

[G Jones]

I always just break out the real and imag parts before going to matlab
workspace
On Oct 3, 2013 4:23 PM, Ross Williamson rwilliam...@astro.caltech.edu
wrote:

 Hi,

 I'm trying to implement a test suite for a correlator and I'm having
 serious problems with my understanding of fi.  The output of the fft
 stage is UFIX 36_0.  I capture that in a matlab variable (say
 fft_out0).  All I want to do is split that up into Re and Im parts at
 FIX 18_17. I'm finding this rather difficult to do in matlab
 (especially because simple bit operations such as   and
 representing numbers via 0x notation do not work).

 If for example I try and convert the output from matlab

 fi(fft_out0,0,36,0) I still get a fractional number which baffles me.

 Is there a way to take this UFIX36_0, split into two FIX 18_17 and
 turn it into a complex number?

 Ross

 p.s. I'm using the unbus blocks to create the simulink output. I don't
 want to manually add gateways from every re_im block unless I really
 have to.

 (p.p.s I'm coming from scipy where this would be trivial hence the
 want to throw the toys out of the pram)

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

Re: [casper] system.twx missing

[G Jones]

The timing was so bad that it didn't get beyond the mapping stage.
Follow the instructions in the error message:
Please use the Timing Analyzer (GUI) or TRCE (command line) with the
Mapped NCD

so run the $XILINX/settings64.sh and then timingan and use the open
design option to open the system_map.ncd (or something like that, I'm
going from memory) in the implementation directory.

Glenn

On Wed, Oct 2, 2013 at 7:39 AM, Andrea Mattana matt...@ira.inaf.it wrote:
 Hi all,

 I'm compiling a model file for ROACH1 but I have to solve some timing
 constraints which are not met. Unfortunately, the system.twx file to
 be opened with the timing analyzer which should be found in
 XPS_R..BASE/implementations/ is missing.

 Do you have an idea?

 Cheers,
 Andrea



 Running delay-based LUT packing...
 Updating timing models...
 ERROR:Pack:1653 - At least one timing constraint is impossible to meet because
component delays alone exceed the constraint. A timing constraint summary
below shows the failing constraints (preceded with an Asterisk (*)). Please
use the Timing Analyzer (GUI) or TRCE (command line) with the Mapped NCD 
 and
PCF files to identify which constraints and paths are failing because of 
 the
component delays alone. If the failing path(s) is mapped to Xilinx 
 components
as expected, consider relaxing the constraint. If it is not mapped to
components as expected, re-evaluate your HDL and how synthesis is 
 optimizing
the path. To allow the tools to bypass this error, set the environment
variable XIL_TIMING_ALLOW_IMPOSSIBLE to 1.


For more information about the Timing Analyzer, consult the Xilinx Timing
Analyzer Reference manual; for more information on TRCE, consult the Xilinx
Command Line Tools User Guide TRACE chapter.
 INFO:Timing:3386 - Intersecting Constraints found and resolved.  For more
information, see the TSI report.  Please consult the Xilinx Command Line
Tools User Guide for information on generating a TSI report.
 INFO:Timing:3284 - This timing report was generated using estimated delay
information.  For accurate numbers, please refer to the post Place and 
 Route
timing report.
 Number of Timing Constraints that were not applied: 3

 Asterisk (*) preceding a constraint indicates it was not met.
This may be due to a setup or hold violation.

 --
   Constraint|Check| Worst Case
 |  Best Case | Timing |   Timing
 | |Slack
 | Achievable | Errors |Score
 --
 * PERIOD analysis for net mad_corr_beam_x6 | SETUP   |
 -3.440ns| 9.690ns| 113|  272325
   4_adc_fab_phase_gen/mad_corr_beam_x64_adc | HOLD|
 -0.179ns||6891|  366231
   _fab_phase_gen/CLK0_BUF derived from  PE | |
 |||
   RIOD analysis for net mad_corr_beam_x64_ | |
 |||
   adc/fab_clk1 derived from NET mad_corr_ | |
 |||
   beam_x64_adc/mad_corr_beam_x64_adc/x64_ad | |
 |||
   c_infrastructure_inst/adc_clk_ibufds PER | |
 |||
   IOD = 4.1667 ns HIGH 50% multiplied by 1. | |
 |||
   50 to 6.250 nS and duty cycle corrected t | |
 |||
   o HIGH 3.125 nS   duty cycle corrected to | |
 |||
6.250 nS  HIGH 3.125 nS  | |
 |||
 --
 * TS_mgt_clk_0 = PERIOD TIMEGRP mgt_clk_0 | SETUP   |
 3.803ns| 2.597ns|   0|   0
156.25 MHz HIGH 50%  | HOLD|
 -1.513ns|| 218|  146110
 --
 * TS_mgt_clk_mult_2_b = PERIOD TIMEGRP mgt | SETUP   |
 5.500ns| 0.900ns|   0|   0
   _clk_mult_2_b 156.25 MHz HIGH 50%| HOLD|
 -0.204ns||  18|3672
 --
   NET mad_corr_beam_x64_adc/mad_corr_beam_ | MINLOWPULSE |
 0.566ns| 3.600ns|   0|   0
   x64_adc/x64_adc_infrastructure_inst/adc_c | |
 |||
   lk_ibufds PERIOD = 4.1667 ns HIGH 50%| |
 |||
 --
   PERIOD analysis for net mad_corr_beam_x6 | SETUP   |
 5.132ns| 1.118ns|   0|  

Re: [casper] Matlab components for toolflow

[G Jones]

/licenses/license.dat:/home/observer/tools/MATLAB/R2012b/licenses/license_fpgadev_277254_R2012b.lic
  Licensing error: -5,357.
  Simulink:Masking:Bad_Init_Commands: Error in
 'fft_wideband_real_core/fft_wideband_real/fft_direct/butterfly0_0/twiddle/coeff_gen/feedback_osc':
 Initialization commands cannot be evaluated.
  Backtrace 1: reuse_block:138
  Backtrace 2: coeff_gen_init:498
  Backtrace 3: reuse_block:51
  Backtrace 4: add_convert_init:496
  Backtrace 5: draw_basic_partial_cycle:407
  Backtrace 6: cosin_init:165
  Backtrace 7: xlUpdateIcon:207
  Backtrace 8: xlBlockLoadCallback:79
  Backtrace 9: UpdateDiagramCB:221
 
  If I turn OFF the option Generate coeffs with multipliers where
 useful, these messages do not appear. Still, I get the following error:
  Error in
 'fft_wideband_real_core/fft_wideband_real/fft_biplex_real_4x/biplex_core/fft_stage_10/butterfly_direct/twiddle/coeff_gen':
 Initialization commands cannot be evaluated.
 
 
  Caused by:
  Error in
 'fft_wideband_real_core/fft_wideband_real/fft_biplex_real_4x/biplex_core/fft_stage_10/butterfly_direct/twiddle/coeff_gen/cosin':
 Initialization commands cannot be evaluated.
 
  Unable to check out a license for the Fixed-Point Toolbox.
 
 
 
 
 
  I will let you know if I find something more.
 
 
  Thanks,
 
 
 
 
  Nimish
 
 
 
 
 
 
 
  On Tue, Sep 24, 2013 at 7:36 PM, David MacMahon 
 dav...@astro.berkeley.edu wrote:
  Thanks.  I was hoping to narrow it down a little more than that.
  There's a lot of stuff inside that little green block!
 
  Dave
 
  On Sep 24, 2013, at 4:33 PM, Nimish Sane wrote:
 
  To be precise, that is the only green block in the design apart from
 bunch of gateway blocks and XSG block (as I am black boxing it).
 
  Thanks,
 
  Nimish
 
 
  On Tue, Sep 24, 2013 at 7:32 PM, Nimish Sane nimishs...@gmail.com
 wrote:
  The design only has fft_wideband_real block, and whenever I click
 Apply/Ok or Update Diagram, I get these error messages. These are the
 only error messages I see in Matlab window. So it is definitely the
 fft_wideband_real block.
 
  Thanks,
 
  Nimish
 
 
  On Tue, Sep 24, 2013 at 7:30 PM, David MacMahon 
 dav...@astro.berkeley.edu wrote:
  Thanks, Nimish,
 
  Is there any other info that might help pinpoint which block and/or
 init script is causing Matlab to look for a Fixed_Point_Tollbox license?
 
  Thanks,
  Dave
 
  On Sep 24, 2013, at 4:21 PM, Nimish Sane wrote:
 
  License checkout failed.
  License Manager Error -5
  Cannot find a license for Fixed_Point_Toolbox.
 
  Troubleshoot this issue by visiting:
  http://www.mathworks.com/support/lme/R2012b/5
 
  Diagnostic Information:
  Feature: Fixed_Point_Toolbox
  License path:
 /home/observer/.matlab/R2012b_licenses:/home/observer/tools/MATLAB/R2012b/licenses/license.dat:/home/observer/tools/MATLAB/R2012b/licenses/license_fpgadev_277254_R2012b.lic
  Licensing error: -5,357.
 
  Nimish
 
 
  On Tue, Sep 24, 2013 at 5:45 PM, David MacMahon 
 dav...@astro.berkeley.edu wrote:
  Hi, Nimish,
 
  What error messages are you getting?
 
  Thanks,
  Dave
 
  On Sep 24, 2013, at 2:28 PM, Nimish Sane wrote:
 
  Hi all,
 
  A question related to this:
 
  Like Glenn, we never had Fixed point toolboxes (Fixed point Toolbox and
 Simulink Fixed point) installed, and still were able to compile our
 correlator designs using 11.5 and Matlab2009b.
 
  I recently upgraded to ISE 14.5 with Matlab 2012b as well as upgraded
 libraries to the latest version of casper-astro/mlib_devel. Even in the
 current installation, we do not have Fixed point toolboxes (names have
 changed to Fixed-point designer Toolbox, Simulink Fixed-point as Jonathan
 has mentioned).
 
  The current fft_wideband_real block has some differences compared to
 the older version that I was using so far and it seems it now requires
 Fixed-point Toolbox. I am getting errors that this particular toolbox has
 not been installed. I am not sure if there are other blocks that give
 similar errors. Does anyone have any experience with this and provide some
 insight as to how to deal with this situation?
 
  Specifically,
  (1) Is there any way to use the latest fft_wideband_real block without
 Fixed-point Toolboxes? (Glenn, have you tried this?)
  (2) Does one have to install both the Fixed-point toolboxes
 (Fixed-point designer Toolbox, Simulink Fixed-point) or just the
 Fixed-point designer Toolbox?
 
  (I have attached lists of toolboxes in our previous and current
 installation.)
 
  Thanks a lot,
 
  Nimish
 
 
  On Tue, Sep 17, 2013 at 7:20 PM, G Jones glenn.calt...@gmail.com
 wrote:
  As one data point I'm successfully compiling designs w/o the fixed
 point toolboxes. I haven't tried simulating a large design which is where
 it's claimed to be needed with busses wider than 53 bits or whatever it is
 
  On Sep 17, 2013 7:15 PM, Jonathan Weintroub 
 jweintr...@cfa.harvard.edu wrote:
  Hi fellow CASPERians,
 
  This is a question that comes up periodically.  At SAO we are now
 paying full fare

Re: [casper] Problem with VACC block

[G Jones]

I've done some work on that block and it definitely has some bugs. I
suggest making a model with the gavrt vacc block which I made a long time
ago and is much more thoroughly tested, and then comparing the behavior to
the xblocks version and finding the issues for your particular use case
that way. The block needs some maintenance but I haven't had the time
myself.

Glenn
On Sep 23, 2013 8:39 PM, Juan Antonio Lopez Martin juan...@die.upm.es
wrote:


 Hi all,

 I am having trouble with the VACC (vector accumulator block) that is in
 the
 'CASPER xBlocks DSP Blockset' library.  We are using it for the Splash
 spectrometer, and we are making the simulations with Simulink
 (Matlab R2012a version).

 - Does anyone know who has designed this block (VACC), so that we can
 contact him to try to solve the problem?

 In particular, we have found that if we set the number of accumulations
 to 40
 frames or less we obtain the correct results, but if the number of
 accumulations
 is set to 70 or more frames, the output valid signal is always 0... Any
 possibilities
 for this? (the parameters of the block are: 11, 1, 10, 1, 32, 0, 64, 0,
 1, 2, 2, 1, 0)

 Suggestions are welcome!

 Many thanks,

 Juan Antonio.-

Re: [casper] Matlab components for toolflow

[G Jones]

As one data point I'm successfully compiling designs w/o the fixed point
toolboxes. I haven't tried simulating a large design which is where it's
claimed to be needed with busses wider than 53 bits or whatever it is
On Sep 17, 2013 7:15 PM, Jonathan Weintroub jweintr...@cfa.harvard.edu
wrote:

 Hi fellow CASPERians,

 This is a question that comes up periodically.  At SAO we are now paying
 full fare for Matlab licenses so the cost impact of an imperfect
 understanding can be significant.

 The latest MSSGE wiki page is:


 https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.5_and_Matlab_2012b

 However this page does not mention Matlab optional components
 (historically termed toolboxes and blocksets).

 There are clues in an earlier setup page:

 https://casper.berkeley.edu/wiki/MSSGE_Toolflow_Setup

 from which it appears one needs something like:

 Fixed-Point Toolbox

 Signal Processing Blockset

 Signal Processing Toolbox

 Simulink Fixed Point


 Each time I buy a new license I iterate on these components with the
 Matlab distributer.  The terminology changes year by year and I am
 currently being quoted on the following components, in addition to the base
 Matlab and Simulink distributions:

 SIGNAL PROCESSING TOOLBOX, V2013A

 SIMULINK FIXED POINT, V2012B

 DSP SYSTEM TOOLBOX, V2013A

 FIXED-POINT DESIGNER TOOLBOX, V2013A,

 (sorry about the all-caps which pasted in directly from the quotation).

 So it is still four components, but the names have changed. The term
 blockset seems to have evolved out in favor of toolbox, one of the signal
 processings has morphed into DSP, and the fixed point toolbox now has
 designer.  Appropriately enough the price for this latter designer
 component alone has more than doubled in a year to over $2k per seat.

 Having set the scene, my two questions are:

 1.  Are we ordering the right components?

 2.  Do we really need all these components?
 (At one point I seem to recall hearing the fixed point stuff is to some
 extent optional, though the ability to simulate properly at the Simulink
 level is important to us.)

 Subject to confirmation from the tool flow experts, I will be happy to
 update the wiki notes with current information.

 Thanks,

 Jonathan

Re: [casper] progdev fails on roach2

[G Jones]

Hi Jason,
This problem looks a bit different than the one Paul was seeing (but
perhaps is related)... In the case you provided, it looks like
tcpborphserver3 may have crashed.
There is another ROACH2 programming problem seen which shows the
following in the telnet session:

?progdev dibas_inco_2048_t12_w095_p00_2
013_Aug_05_1926.bof
#log info 949739059032 raw
attempting\_to\_program\_dibas_inco_2048_t12_w095_p00_2013_Aug_05_1926.bof
#log info 949739059041 raw
attempting\_to\_program\_bitstream\_of\_19586188\_bytes\_to\_device\_/dev/roach/config
#fpga loaded
#log error 949739059487 raw
unable\_to\_map\_file\_/dev/roach/mem:\_Cannot\_allocate\_memory
#log error 949739059489 raw
unable\_to\_program\_bit\_stream\_from\_dibas_inco_2048_t12_w095_p00_2013_Aug_05_1926.bof
!progdev fail

This looks to me like some sort of bug in tcpborphserver or the kernel.

Anyone seen something like this or have any ideas/suggestions for
tracking this down?

Glenn

On Wed, Aug 14, 2013 at 8:17 AM, Jason Ray j...@nrao.edu wrote:
 All,

 Occasionally I've noticed (maybe a handful of times over the past few
 months) that progdev will fail with our roach2 boards.  After working fine
 for long periods, it will fail to program out of nowhere and the only fix is
 to reboot the roach2.

 I copied/pasted the python error dialog below.

 Has anyone else had this issue?

 Thanks,
 Jason




 ERROR: An unexpected error occurred while tokenizing input
 The following traceback may be corrupted or invalid
 The error message is: ('EOF in multi-line statement', (287, 0))

 ---
 KatcpClientError  Traceback (most recent call last)
 /users/jray/dibas_inco_setup.py in module()
  48
  49 # Latest 4096ch

 --- 50 fpga.progdev('dibas_inco_4096_t12_w095_z00_2013_Aug_13_1943.bof')
  51
  52


 /opt/local/lib/python2.7/site-packages/corr/katcp_wrapper.pyc in
 progdev(self, boffile)
 108 self._logger.info(Deprogramming FPGA...
 %s.%(reply.arguments[0]))
 109 else:
 -- 110 reply, informs = self._request(progdev, boffile)
 111 self._logger.info(Programming FPGA with %s...
 %s.%(boffile,reply.arguments[0]))
 112 return reply.arguments[0]

 /opt/local/lib/python2.7/site-packages/corr/katcp_wrapper.pyc in
 _request(self, name, *args)
  59
  60 request = Message.request(name, *args)
 --- 61 reply, informs =
 self.blocking_request(request,keepalive=True)
  62
  63 if reply.arguments[0] != Message.OK:

 /opt/local/lib/python2.7/site-packages/katcp/client.pyc in
 blocking_request(self, msg, timeout, keepalive)
 591
 592 try:
 -- 593 self.request(msg)
 594 while True:
 595 self._request_end.wait(timeout)

 /opt/local/lib/python2.7/site-packages/katcp/client.pyc in request(self,
 msg)
  88 
  89 assert(msg.mtype == Message.REQUEST)
 --- 90 self.send_message(msg)
  91
  92 def send_message(self, msg):

 /opt/local/lib/python2.7/site-packages/katcp/client.pyc in
 send_message(self, msg)
 113 try:
 114 if sock is None:
 -- 115 raise KatcpClientError(Client not connected)
 116
 117 while totalsent  datalen:

 KatcpClientError: Client not connected

Re: [casper] ROACH2 dies on fpga.read(...)

[G Jones]

Below is a message I wrote with more about the problems we had at
NRAO, which did not make it to the list. By the way, others at NRAO
are using a recent version of the repository and have had better luck,
but based on your experience I wonder if there is still some subtle
issue with marginal signals or timing on some boards.

Glenn

Previous message:

The problem was because of some errors that crept into the ska-sa
repository. I had to revert to a commit BEFORE this one
https://github.com/ska-sa/mlib_devel/commit/bad95b18fe79146d288607e5fe3c0360c071c2ad
 (easy to remember since the hash starts with 'bad' :)
Something about this EPB to OPB optimization they did messes things
up. In theory they reverted these changes, but I found it still was
present last time I looked. And this is of course the least fun kind
of problem to keep checking if it's still there...
Note I had other issues with ROACH1s with this commit too.


On Thu, Jul 11, 2013 at 8:23 PM, Ryan Monroe ryan.m.mon...@gmail.com wrote:
 Thanks!  Sounds good

 Also: I take back the deterministic part.  The other roach started having
 the problem too, and it might have something to do with read lengths.  More
 to follow (eventually)

 --Ryan Monroe
 626.773.0805


 On 07/11/2013 05:20 PM, John Ford wrote:

 Hi Ryan.  We had this problem, which appeared to be a lockup.  I think
 that Glenn and some others corresponded about it, and it was due to trying
 to read/write bytes instead of words over the opb bus with a buggy kernel
 or a buggy library.

 You might search through the mailing list for Glenn's name in about
 November of last year.

 John


 Hey all,

 I'm trying to test out a new bit file (it uses the pcore feature and
 has 4 black boxes under the hood for what it's worth). *On one ROACH2 it
 works just fine* (in the context of this problem).

 On the other one, for ~1/5 of the registers, upon reading that register
 the ROACH2 stops responding to all katcp commands.  From dmesg, it looks
 like tcpborphserver is crashing.  It appears that the registers which
 kill it are deterministic across programmings. It also looks like the
 registers which fail are all shared_brams, but there is nothing
 exceptional about the ones which fail, imho

 Attached are the results of a python script on the two roaches, and a
 dmesg output of the failed board.  In addition, pictures of the
 configuration for both roaches.

 Anyone seen this before?

 --
 --Ryan Monroe
 626.773.0805

Re: [casper] Fwd: how to stop casper_xps?

[G Jones]

Kill matlab :)

seriously it's pretty difficult. If it's gotten to the point of
running the edk backend, you can try to kill an xst or map or par
process, which will then cause the matlab script to say error running
the toolflow and return you to the matlab prompt.

Glenn

On Fri, Jun 14, 2013 at 1:34 PM, John Ford jf...@nrao.edu wrote:
 Hi all.  Posted for Paul

  Original Message 
 Subject:how to stop casper_xps?
 Date:   Fri, 14 Jun 2013 12:53:22 -0400
 From:   Paul Marganian pmarg...@gb.nrao.edu
 To: casper@lists.berkeley.edu



 Hi all,
 Sorry if this is a silly question: once you click 'Run XPS' on the
 casper_xps GUI, is there any way to cancel the compilation process?
 Thanks
 Paul Marganian

[casper] MUSIC ADC/DAC 4x interface

[G Jones]

Hi,
Is anyone using the adc_mkid_4x and dac_mkid_4x interfaces to the
MUSIC ADC/DAC board? When I use these blocks I get sporadic bit
glitches on both the ADC and DAC most of the time, even though timing
comes out fine. Reprogramming the ROACH many times and trying many
ADC/DAC clock rates sometimes reduces or eliminates the glitches, but
not particularly reliably. This smells like some sort of constraint is
not getting set properly in the UCF. There was some discussion of a
problem like this for the adc2x14_400 block, but that was the 2x
interface and seems to be unrelated to this. I am clocking my FPGA off
of the ADC (ADC1) with an FPGA clock of 120 MHz and an ADC and DAC
clocks at 480 MHz.

I just built a test design with the adc_mkid and dac_mkid (2x)
interfaces. They seem to work fine w/o glitches.

Anyone experienced this problem and have  a solution?

Thanks,
Glenn

Re: [casper] 38 PFB's on a virtex-6?

[G Jones]

Hi David,
Traditionally, the CASPER libraries are much better at processing data
many times the rate of the FPGA rather than the other way around. So
while your suggestion of reusing multipliers is of course a good one,
it's generally not well implemented in the CASPER libraries. You might
consider using Xilinx filters for the PFB_FIR section (perhaps)
followed by CASPER FFTs. The FFTs could be shared amongst many lower
bandwidth signals by sending one frame of data at a time through the
FFT.

You can estimate the resource usage by drilling down into the blocks
(look under mask) and manually counting. Or you can make a couple test
designs, count the resources (planahead is convenient for doing this)
and the figure out how it's scaling. Good to check this against your
estimate to make sure it's doing things the way you expect. Most
blocks have an option to explicitly use DSP48s or general logic for
the implementation.

Glenn

On Mon, Jun 10, 2013 at 12:07 PM, David Saroff dsar...@nrao.edu wrote:
 Short of compiling a design, can the resource usage of a PFB yellow block
 be seen?

 If the data rate is some submultiple of the FPGA clock, say 50 MSPS and
 200 MHz is there a natural way to share resources?

 The question's context:
 38 dipole antennae of the focal plane array for the green bank telescope.
 Signal from each of the 38 is sampled at 50 MSPS, digitized to 12 bits.
 What frequency resolution fits on a virtex-6? That is what is the number
 of taps P and fft bins n that will fit?

 Count multipliers as dsp48 blocks.

 2000/38 =~ 50 dsp48 blocks per signal. That doesn't seem like enough. If
 there is a way to resource share, is there a factor of 200MHz/50MHz = 4
 available ideally? Then it looks more like 4 * 50 = 200 dsp48's per
 channel. That still doesn't seem like enough.

 What about a sample rate of 2.5 MHz? Then the potential reuse multiplier
 is 200MHz/2.5MHz = 80 and the number of multiplies per channel is a more
 comfortable 80 * 50 = 4000 The bandwidth is less for the 2.5 MSPS vrs 50
 MSPS, by a factor of 1/20th. That makes fewer fft bins n necessary, so
 might the advantage of lower sampling rates and narrower band widths be
 quadratic?

 Summary
 1)when we parametrize a PFB, can we conveniently see how many dsp48s and
 slices, etc it requires?

 2)if a PFB receives samples slower than the system clock, is there a way
 to share it between channels?

 some embarrassment for the beginner's questions.

Re: [casper] Setting up 10gbe core for ROACH2

[G Jones]

H Dale,
Do you have a lot of other ARP traffic on the network (from a BEE2 for
example?) We ran into an issue where the current implementation of
tcpborphserver3 (which does all of the tgtap stuff; there is no
separate process for it now) will not send enough ARP requests to
populate it's ARP table if there is significant other ARP traffic on
the network. This is an optimization for situations where you have a
large number of ROACH2s on a network to avoid being overwhelmed with
ARP broadcasts. However, it also means it flat out doesn't work if you
have a BEE2 on the network. If this sounds like your problem (try
sniffing the network and see what's flowing around), I'll try to dig
up old emails with the solution we concocted. It should be in the
casper list archive.

Glenn

On Fri, Jun 7, 2013 at 9:14 AM, Gary, Dale E. dale.e.g...@njit.edu wrote:
 Hi All,

 We previously were successful in setting up the 10gbe core for ROACH1 using
 tap_start, which I believe resulted in a process tgtap appearing in the
 ROACH.

 I am using the same method for ROACH2 (using the latest ROACH2 rev 2 file
 system loaded via netboot), and there is no reported error, but the ARP
 table does not contain the MAC address for the destination IP address, and
 when I check the processes running on the ROACH2 I do not see tgtap.

 Has the procedure changed at all, or is there something I am doing wrong?

 Thanks,
 Dale

 Here are the relevant katcp python calls we are using:

 # Configuration Parameters for 10 GbE ports.
 dest_ip = 10 * ( 2 ** 24 ) + 101 # DPP_IP 10.0.0.101
 fabric_port = 6
 source_ip = 10 * ( 2 ** 24) + 11 # ROACH1, SLOT 0, CHANNEL 0: 10.0.0.11
 mac_base = (2  40) + (2  32)

 # Configuring 10 Gbe core Tx_P
 print 'Configuring transmitter core...',
 sys.stdout.flush()
 fpga.tap_start('tapP1',tx_core_name, mac_base + source_ip, source_ip,
 fabric_port)
 print 'done'

 print 'Setting-up DPP IP and port information...',
 sys.stdout.flush()
 fpga.wordwrite('f_ctrl_dpp_ip', 0, hex(dest_ip))
 fpga.wordwrite('f_ctrl_dpp_port', 0, hex(fabric_port))
 print 'done'

 # Reset 10 GbE cores
 print 'Resetting 10 GbE core...',
 sys.stdout.flush()
 fpga.wordwrite('f_ctrl_rst', 0, hex(1))
 fpga.wordwrite('f_ctrl_rst', 0, hex(0))
 print 'done'

 time.sleep(2)

 # Print ARP table
 print '\n===\n'
 print '10GbE Transmitter core details:'
 print '\n===\n'
 print Note that for some IP address values, only the lower 8 bits are
 valid!
 fpga.print_10gbe_core_details( tx_core_name, arp=True )

 This ARP table is correct for the source_ip, but all FF for the MAC address
 of the dest_ip.

Re: [casper] Setting up 10gbe core for ROACH2

[G Jones]

It requires recompiling tcpborphserver3. So I cloned the ska-sa/katcp
directory into the /boffiles directory on the ROACH 2, hacked the
source, built it on the ROACH 2 (which requires mounting the
filesystem rw so you can apt-get the libz package and perhaps
another), and then run that version of tcpborphserver3.

Glenn

On Fri, Jun 7, 2013 at 9:45 AM, Gary, Dale E. dale.e.g...@njit.edu wrote:
 Hi Glenn,

 I recalled your original messages, and just located them again.  There it
 says you were going to disable burst checking.  How does one do that?  We do
 not have a BEE2 on the network, but it is the main LAN with a lot of devices
 on it, so this could be our problem.

 Thanks,
 Dale


 On Fri, Jun 7, 2013 at 1:23 PM, G Jones glenn.calt...@gmail.com wrote:

 H Dale,
 Do you have a lot of other ARP traffic on the network (from a BEE2 for
 example?) We ran into an issue where the current implementation of
 tcpborphserver3 (which does all of the tgtap stuff; there is no
 separate process for it now) will not send enough ARP requests to
 populate it's ARP table if there is significant other ARP traffic on
 the network. This is an optimization for situations where you have a
 large number of ROACH2s on a network to avoid being overwhelmed with
 ARP broadcasts. However, it also means it flat out doesn't work if you
 have a BEE2 on the network. If this sounds like your problem (try
 sniffing the network and see what's flowing around), I'll try to dig
 up old emails with the solution we concocted. It should be in the
 casper list archive.

 Glenn

 On Fri, Jun 7, 2013 at 9:14 AM, Gary, Dale E. dale.e.g...@njit.edu
 wrote:
  Hi All,
 
  We previously were successful in setting up the 10gbe core for ROACH1
  using
  tap_start, which I believe resulted in a process tgtap appearing in the
  ROACH.
 
  I am using the same method for ROACH2 (using the latest ROACH2 rev 2
  file
  system loaded via netboot), and there is no reported error, but the ARP
  table does not contain the MAC address for the destination IP address,
  and
  when I check the processes running on the ROACH2 I do not see tgtap.
 
  Has the procedure changed at all, or is there something I am doing
  wrong?
 
  Thanks,
  Dale
 
  Here are the relevant katcp python calls we are using:
 
  # Configuration Parameters for 10 GbE ports.
  dest_ip = 10 * ( 2 ** 24 ) + 101 # DPP_IP 10.0.0.101
  fabric_port = 6
  source_ip = 10 * ( 2 ** 24) + 11 # ROACH1, SLOT 0, CHANNEL 0: 10.0.0.11
  mac_base = (2  40) + (2  32)
 
  # Configuring 10 Gbe core Tx_P
  print 'Configuring transmitter core...',
  sys.stdout.flush()
  fpga.tap_start('tapP1',tx_core_name, mac_base + source_ip,
  source_ip,
  fabric_port)
  print 'done'
 
  print 'Setting-up DPP IP and port information...',
  sys.stdout.flush()
  fpga.wordwrite('f_ctrl_dpp_ip', 0, hex(dest_ip))
  fpga.wordwrite('f_ctrl_dpp_port', 0, hex(fabric_port))
  print 'done'
 
  # Reset 10 GbE cores
  print 'Resetting 10 GbE core...',
  sys.stdout.flush()
  fpga.wordwrite('f_ctrl_rst', 0, hex(1))
  fpga.wordwrite('f_ctrl_rst', 0, hex(0))
  print 'done'
 
  time.sleep(2)
 
  # Print ARP table
  print '\n===\n'
  print '10GbE Transmitter core details:'
  print '\n===\n'
  print Note that for some IP address values, only the lower 8 bits
  are
  valid!
  fpga.print_10gbe_core_details( tx_core_name, arp=True )
 
  This ARP table is correct for the source_ip, but all FF for the MAC
  address
  of the dest_ip.
 
 
 
 
 

Re: [casper] netbooting ROACH2

[G Jones]

I think John has the right idea: it looks like your server is serving
a ROACH 1 uimage to your ROACH 2. We ran into this at NRAO once before
as well, but perhaps the other way around.

On Thu, Jun 6, 2013 at 9:51 AM, John Ford jf...@nrao.edu wrote:
 Hi John,

 Thanks for the reply.  My uImage checksum for uImage-r2borph3 agrees with
 yours.  I do not have any uImage-current, and do not understand why there
 would be two uImages.  I will assume you are running two different ROACH2
 versions and that I should be using only the uImage-r2borph3 one, but
 please correct me if not.


 I should have explained more fully.   We have a custom uImage that enables
 both of the IIC ports on the ROACH2 for use by users.  That's the
 uImage-current that we use, but the other one worked fine besides the IIC
 issue.

 I have the u-boot.bin (with the same checksum), but am not using it.  I am
 confused about what steps I need to take, and thought I could just follow
 the same procedure for ROACH-1, but do I first have to update the u-boot
 as
 in these instructions?

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

 I think you do need the newest uboot, but I'm not positive.  But I think
 that one main thing is that you don't have the right kernel somehow being
 loaded.  I think that your server is serving the wrong one, since what was
 in the mail showed an older kernel being started up:

 Linux version 2.6.25-svn3489 (dave@lapster) (gcc version 4.2.2) #6 Fri
 Aug
  12 09:36:28 SAST 2011

 Which is (nearly) the same as our roach1 kernel image:

 Yes, Master1009 strings uImage-roach1 | more
 Linux-2.6.25-svn2338
 ...

 Whereas our roach2 kernel looks like this:

 Yes, Master1007 strings uImage-r2borph3 | more
 Linux-3.7.0-rc2+
 ...


 I actually tried it, but our network seems to be down at the moment.  What
 about romfs?  Is this only needed for soloboot?

 I think that's right.  The file system should be on the NFS server.
 Here's what our mounts look like:

 root@vegasr2-2:~# mount
 rootfs on / type rootfs (rw)
 10.16.96.203:/export/home/tofu/cicadaroots/vegasr2/ on / type nfs
 (ro,noatime,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=10.16.96.203,mountvers=1,mountproto=udp,local_lock=all,addr=10.16.96.203)
 proc on /proc type proc (rw,relatime)
 sysfs on /sys type sysfs (rw,relatime)
 devpts on /dev/pts type devpts (rw,noexec,relatime,mode=620)
 tmpfs0 on /var/tmp type tmpfs (rw,relatime,size=32768k)
 tmpfs1 on /tmp type tmpfs (rw,relatime,size=16384k)
 root@vegasr2-2:~#

 John


 Thanks,
 Dale


 On Thu, Jun 6, 2013 at 4:44 AM, John Ford jf...@nrao.edu wrote:

 In our R2 systems, we have the following kernel:

 root@vegasr2-2:~# uname -a
 Linux vegasr2-2 3.7.0-rc2+ #20 Fri Jan 4 18:04:26 SAST 2013 ppc
 GNU/Linux

 I'm pretty sure the Roach-2 kernels are all 3.x.

 Can you get a checksum (md5sum) of the uimage? I think you have the
 right
 one, but it may be too old.

 Yes, Master1017 md5sum uImage-current
 300753db387044c3cb8f5f9d92c4fb37  uImage-current

 We also used the following:
 Yes, Master1018 md5sum uImage-r2borph3
 ac6feb36b96c410a336fb3103fafb82c  uImage-r2borph3

 Our uboot is:

 Yes, Master1022 md5sum u-boot.bin
 e396454ffa9d1e2dcbf87abf9eafccba  u-boot.bin

 Hope this helps!

 John

  Posting on behalf of Dale. Please see the message below.
 
  Thanks,
 
  Nimish
 
 
  -- Forwarded message --
  From: Gary, Dale E. dale.e.g...@njit.edu
  To: casper list casper@lists.berkeley.edu
  Cc:
  Date: Thu, 6 Jun 2013 00:40:25 +
  Subject: netbooting ROACH2
  Hi Casperites,
 
  I am setting up a ROACH2 rev2 for netbooting, and I think I am almost
  there, but the ROACH hangs during the boot process, which suggests
 either
  a
  setup problem or the wrong Image or filesystem.  The uImage is
  uImage-r2borph3, and the filesystem is
  roach2-debian-fs-snapshot-24-10-2012.tar.gz.  According to the output
  during the boot process (see below), I appear to have bootp and tftp
 set
  up
  correctly.  Can anyone spot the problem based on this information, or
  suggest a way to get more information on what might have gone wrong?
  Perhaps something to do with the USB device?
 
  Thanks,
  Dale
 
  ===Output of boot process
  Waiting for PHY auto negotiation to complete done
  ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
  BOOTP broadcast 1
  DHCP client bound to address 192.168.24.121
  Using ppc_4xx_eth0 device
  TFTP from server 192.100.16.206; our IP address is 192.168.24.121;
 sending
  through gateway 192.168.24.1
  Filename 'uImage'.
  Load address: 0x400
  Loading:
 #
 
  #
 
  #
 
  #
   
  done
  Bytes transferred = 

[casper] tcpborphserver3 logging with network mounted ROACH II

[G Jones]

Hi,
We're experiencing some intermittent failures where it appears the
FPGA is spontaneously deprogramming on the ROACH II. We'd like to try
to track this down by turning on logging in tcpborphserver3. Has
anyone done this for a network mounted ROACH II? Should we mount an
extra directory as r+w to store the logs? Looking for advice on best
practices or at least something that works.

Thanks,
Glenn

[casper] r2case_event() in dmesg

[G Jones]

Hi,
Anyone know why there are a bunch of messages like this in dmesg on a ROACH II:

r2case_event(): Got type 11, code 8, value 1
attempting led toggle
About to toggle cpu_rdy pin7r2case_event(): Got type 11, code 8, value 0
attempting led toggle
About to toggle cpu_rdy pin7r2case_event(): Got type 11, code 8, value 1
attempting led toggle
About to toggle cpu_rdy pin7r2case_event(): Got type 11, code 8, value 0
attempting led toggle


Thanks,
Glenn

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

[G Jones]

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

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

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

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

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

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

Glenn

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

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

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

 roach VMA close
 roach release mem called

 -

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

 Any ideas where to look for this problem?

 Thanks,
 Glenn

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

[G Jones]

Hi Wes,
The problem shows up with both the latest pull from ska-sa and an earlier
one from a couple of months ago. The crashing bof crashes with both and the
working bof works with both. That's why I'm wondering if it's some
interaction with the ADC5G since I presume your designs are mostly with the
katADC?

Has anyone else compiled/run bofs using ADC5G with these latest changes?

Glenn


On Fri, Mar 15, 2013 at 10:19 AM, Wesley New wes...@ska.ac.za wrote:

 Hi Glenn,

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

 Wes


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

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


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

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

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

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

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

 Glenn

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

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

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

 roach VMA close
 roach release mem called

 -

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

 Any ideas where to look for this problem?

 Thanks,
 Glenn

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

[G Jones]

Hi Henno,
I'll send the model separately. Typically the crash occurs within a minute
or two, which corresponds to ~10-30 register/bram read/writes.
Glenn


On Fri, Mar 15, 2013 at 10:25 AM, Henno Kriel he...@ska.ac.za wrote:

 Hi Glenn

 Is it possible to send me you model file?

 I have a fairly sizable design running with these changes, that has many
 register, shared BRAMs and snap blocks, without issues.

 You mentioned that the design crashes after a while - could you give me a
 more precise indication of the time span?

 Regards
 Henno

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

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


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

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

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

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

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

 Glenn

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

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

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

 roach VMA close
 roach release mem called

 -

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

 Any ideas where to look for this problem?

 Thanks,
 Glenn





 --
 Henno Kriel

 DSP Engineer
 Digital Back End
 meerKAT

 SKA South Africa
 Third Floor
 The Park
 Park Road (off Alexandra Road)
 Pinelands
 7405
 Western Cape
 South Africa

 Latitude: -33.94329 (South); Longitude: 18.48945 (East).

 (p) +27 (0)21 506 7300
 (p) +27 (0)21 506 7365 (direct)
 (f) +27 (0)21 506 7375
 (m) +27 (0)84 504 5050

Re: [casper] Question regarding FFT

[G Jones]

Hi Nimish,
My suggestion is to add snapshot blocks triggered on the sync pulse
directly after the FFT and after the blocks that follow it. You can
then look at the signal at each stage and see at which stage that
strange behavior is occurring. You can also add a test vector
generator that puts in a known sequence and see if what comes out
matches what you expect.

Glenn

On Fri, Mar 15, 2013 at 3:14 PM, Nimish Sane nimish.s...@njit.edu wrote:
 Hi all:

 I am attaching a plot for Power of two inputs vs frequency channels. As can
 be seen, we have this persistent problem where some channels at the end just
 do not make any sense. We suspect that there is something going wrong in the
 FFT block. Has anybody seen such behavior before or can think of what may be
 going wrong?

 Following are some specifications that may be useful:
 Hardware: ROACH2 with KATADC.
 ADC Clock: 800 MHz,
 FPGA clock: 200 MHz
 Toolflow: XSG 11.5 with Matlab 2009b with RHEL5.8
 Libraries: SKA
 FFT green block: fft_wideband_real
 FFT size: 2^13 (4096 Output channels)

 Thanks,

 Nimish
 --
 Nimish Sane

 Center for Solar-Terrestrial Research
 New Jersey Institute of Technology
 University Heights

 Newark, NJ 07102-1982 USA

 Tel: (973) 642 4958

 Fax: (973) 596 3617

 nimish.s...@njit.edu

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

[G Jones]

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

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

roach VMA close
roach release mem called

-

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

Any ideas where to look for this problem?

Thanks,
Glenn

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

[G Jones]

Also, I meant to mention, I've checked coreinfo.tab etc and they are
identical between the working and non-working bofs.

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

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

 roach VMA close
 roach release mem called

 -

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

 Any ideas where to look for this problem?

 Thanks,
 Glenn

[casper] 'have_katcp()' missing from katcp_devel

[G Jones]

Hi,
I'm forwarding this message on behalf of Ray Creager at NRAO. In
addition to this question, he was also noticing that KATCP_FLAG_MORE
also disappeared w/o warning.

Glenn

 Original Message 
Subject: 'have_katcp()' missing from katcp_devel
Date: Wed, 13 Mar 2013 16:44:30 -0400
From: Ramon E. Creager rcrea...@nrao.edu
To: casper@lists.berkeley.edu

I've updated to the latest katcp_devel, and 'have_katcp()' is no longer
defined in the library, even though a prototype for it still exists in
'katcp.h'.

Should the prototype not be there as well? Or is the omission of
'have_katcp()' an accident?

Ramon Creager
Software Engineer
NRAO Green Bank

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

[G Jones]

Hi Wes,
Can you elaborate on this MMCM stability problem? Which version of ISE was
it fixed in?
Thanks,
Glenn
On Mar 12, 2013 5:40 AM, Wesley New wes...@ska.ac.za wrote:

 Hi Guy,

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

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

 Regards

 Wes



 On Tue, Mar 12, 2013 at 11:11 AM, Guy kenfack guy.kenf...@gmail.comwrote:

 Hi Marc,
 thank you for answer.

 Now I have another question from my 1st email, I did'nt have an answer.
 it is about the process to generate a boffile compatible with roach2 and
 tcpborph3 using the 11.5 toolflow.
 I'd like to know if there is a trick , which can be used to generate a
 boffile with the current casper_astro_mlib or the old ska_sa_lib , which
 will be compatible with the roach2.

 regards,






 Roach2s which run tcpborphserver3 do not execute bof files,
 they use tcpborphserver3 to program the FPGA using a device
 file. So this is not an error. Use progdev to program the fpga,
 or if you wish to use the commandline

 ~ # kcpcmd progdev r2_tut1_2013_Mar_07_0837.bof

 regards

 marc

Re: [casper] what should I see?

[G Jones]

I think your clock source should be  1 GHz right?  Also, your signal
generator is set to way too high of a level I think. Start with -40
dBm and increase from there.

On Tue, Mar 12, 2013 at 4:10 PM, katherine viviana cortes urbina
kattycort...@gmail.com wrote:
 Dear Casperites,

 1.- I compile the tut3 with 2048 channels, ADC 1 Ghz. The control is via
 katcp server (python library), I run the script tut3.py and the clock source
 (valon 5007) is connected to clk_i of the adc with f_out =2425 MHz, the
 spectrum  generated is attachment:  tut3_clock_2048canales.png , when I
 connect a Signal generator (frecuency 120Mhz , 2Vpp and signal senoidal) to
 SMA +i of the adc , the spectrum is  attachment tut3_2048canales_120MHz.png,
 is this correct? .

 2.- Now, when I compile the tut3 with 32 channels, the script .py change see
 attachments: tut3_32channel.py, is this correct ? . The spectrum
 generated (only with clock source) is tut3_32kcanales_2012_Dec_17_2104.png,
 is this correct? .

 my questions is what should I see (the spectrum)?


 any ideas?

 cheers

 katty

Re: [casper] Errors compiling pfb_fir_real

[G Jones]

The idea is that the tutorials should in theory be tagged with the version
of the libraries they were built against. It's a bit tricky though because
there have been some incompatibilities introduced in the recent versions of
MATLAB.
On Mar 7, 2013 8:03 PM, Ross Williamson rwilliam...@astro.caltech.edu
wrote:

 Hi Glenn,

 Thanks - That fixed that issue but there are a couple more now coming up.
  I'm just assuming that the tutorials are old compared to the ska branch
 and that I'm probably going to have to re-implement them.  Good way to
 learn I guess

 R

 On Thu, Mar 7, 2013 at 4:19 PM, G Jones glenn.calt...@gmail.com wrote:

 There was a recent change to the pfb inner workings that makes it
 incompatible with previous models. Drag a new pfb block into the model and
 set the parameters to those of thee existing block and it should fix it.
  On Mar 7, 2013 7:12 PM, Ross Williamson rwilliam...@astro.caltech.edu
 wrote:

 Dear all,

 I'm getting the following error when compiling any tutorial that uses
 the pfb_fir_real function block.

 Error evaluating parameter 'initVector' in
 'tut3/pfb_fir_real/pol1_in1_coeffs/ROM1'

 I'm running the ska-sa branch on ISE 14.4

 https://github.com/ska-sa/mlib_devel.git

 Anybody seen this error and know how to fix it? I'm investigating at the
 moment.

 Ross

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




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

casper-scm rcs block abandoned?

[G Jones]

Hi,
I was finally looking into the rcs block to start keeping better track of
my designs. I was surprised to find that it's currently broken in
ska-sa/mlib_devel because it assumes the presence of the MLIB_ROOT
environment variable which was renamed in the cleanup to MLIB_DEVEL_PATH.
The init script hasn't been touched in 2 yrs. Is this block still in active
use? Is there a better option I should be considering?

Thanks,
Glenn

Re: [casper] casper Digest, Vol 63, Issue 9

[G Jones]

I just dumped this info on the wiki on the ROACH 2 page since it seems
very useful and didn't appear to be there already.

Glenn

On Wed, Feb 13, 2013 at 2:21 PM, Alec Rust alec.r...@ska.ac.za wrote:
 Hi John. Grab the latest versions from
 https://github.com/ska-sa/roach2_nfs_uboot/.

 If you netboot: copy tcpborphserver3 to nfs_root_directory/usr/local/sbin.
 Tcpbporphserver3 will load automatically when the roach boots.
 If you soloboot (boot the root file system stored in flash), which is the
 easiest please follow these instructions:
 You need to update to the latest romfs which includes the new
 tcpborphserver3. To update:

 ROACH2 Test machine set-up instructions:
 https://docs.google.com/a/ska.ac.za/document/d/1tqw4C6uZ6EULl1OykTFL_vQTnK52UBr0aYqTg44E5wg/edit)

 1. Set up a tftp and dhcp server (see the tftp section in the test machine
 setup instructions).
 2. Create a symlink or rename the romfs image downloaded from github to
 romfs e.g. ln -s  roach2-root-readdebug-2013-02-12.romfs romfs in the tftp
 directory.
 3. Connect to the roach via USB using a terminal emulator: In linux we use
 minicom, please follow the minicom setup instructions in the document.
 4. Switch the roach on or reset and interrupt the boot process
 5. At the uboot prompt type: run tftproot
 6. This takes a long time! About 5 minutes.
 7. type reset and let the board boot linux
 8. Login using root (password is blank)
 9. rm /usr/.keep
 10. reboot -f

 If you do not which to run a dhcp and tftp server you can use run newroot.
 This macro starts a y-modem receiver, the file can now be sent using minicom
 via y-modem protocol, but this takes a long time and you really need a dhcp
 server unless you are going to set the roach ip address manually. You can
 set the IP address by editing /etc/network/interfaces

 To measure temperatures, voltages and currents:
 All sensors are available using kcp commands. You can telnet to the board to
 run kcp commands (telnet board_ip 7147) or if you have access to the console
 you can run the commands using the program kcpcmd (kcpcmd sensor-list note
 that there is no ?)
 ?sensor-list - lists all the sensors
 ?sensor-value - lists all the current values
 ?sensor-sampling sensor_name event - this will give updates when the sensor
 changes.

 If anything is unclear please don't hesitate to ask.

 Regards
 Alec

 On Wed, Feb 13, 2013 at 8:15 PM, Jason Castro jcas...@nrao.edu wrote:

 I recently got a ROACH2 from digicom and I'm trying to upload a bof file.
 My tcpborphserver does not support the KATCP command upload_bof.  I do
 have the command upload which will upload and run a bof file but when I
 read a register something crashes.  According to the previous posts, I
 believe I need to update to tcpborphserver3.  Can someone give me an idea of
 how to do this?  Do I have to find the source then compile and install?
 Does someone have a how-to?

 Thanks,

 Jason Castro
 NRAO


 On 2/12/2013 3:14 PM, casper-requ...@lists.berkeley.edu wrote:

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

 To subscribe or unsubscribe via the World Wide Web, visit

 https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.berkeley.edu

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

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

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


 Today's Topics:

 1. Re: Roach2 configuration and setup (Paul Prozesky)
 2. Re: Roach2 configuration and setup (Marc Welz)


 --

 Message: 1
 Date: Tue, 12 Feb 2013 15:26:11 +0200
 From: Paul Prozesky paul.proze...@gmail.com
 Subject: Re: [casper] Roach2 configuration and setup
 To: LIST CASPER casper@lists.berkeley.edu
 Message-ID:

 CAASPtuoUXfPBh==XarFqvSkS5d=+oymrdce3e9ircmy67jt...@mail.gmail.com
 Content-Type: text/plain; charset=iso-8859-1

 Afternoon Guy

 Regarding question 3... if you're running tcpborphserver3 you can use the
 upload_bof method in the FpgaClient class in corr to upload a bof file to
 your ROACH. I just checked and it took about 12s to copy a boffile using
 this. Once it's uploaded, though, it will skip uploading it unless you
 force it to do so. Use progdev to program the device as usual.

 Regards
 Paul


 On 12 February 2013 00:32, Guy kenfack guy.kenf...@gmail.com wrote:

 Hello,
 we received 2 roach2 boards from digicom (20th dec 2012).we managed to
 configure our minicom with centos6.2 final, and tty usb2.
 I've several questions about the advised version for the uboot and the
 tcborphserver3
 u-boot versionof my boards:
 u-boot 2011.06-rc2-0-gd422dc0-dirty(Nov 8 2012 - :16:04:14)
 #SN : Roach2.2 batch = D#6#10
 #kernel : Linux roach 02 06 0A 3.4.0 - rc3+
 Tcpborphserver3
 1/
 a- how can I find the version of my romfs and also how can 

Re: [casper] CASPER 10 GbE yellow block

[G Jones]

I think it's just a typo and ten_gbe_v2 == 10_gbe_v2

On Wed, Feb 13, 2013 at 5:47 PM, Nimish Sane nimishs...@gmail.com wrote:
 Hi Dave and others,

 I was under the impression that ten_Gbe_v2 was suppose to support ROACH2
 as well. At least, its mask supports parameters specific to ROACH2 (such as
 choice between CX4, SFP+ and ports etc.). Rather, these options are
 available in the mask only for ROACH2.

 Is 10_Gbe_v2 part of SKA-SA github repository now and is that supposed to
 be used instead of ten_Gbe_v2? I have not updated the repository of late
 and have been using ten_Gbe_v2 for my ROACH2 design.

 Thanks,

 Nimish


 On Wed, Feb 13, 2013 at 5:07 PM, David MacMahon dav...@astro.berkeley.edu
 wrote:

 Hi, John,

 My current work is on ROACH2 and the 10_Gbe_v2 block is the only 10 GbE
 block supported on ROACH2 so that's the one I'm currently designing with
 (but not yet using myself).  I'm not sure which block Christopher used in
 the packet generator.  His design ran on a ROACH so it could have been using
 the ten_GbE or ten_Gbe_v2 block.

 Dave

 On Feb 13, 2013, at 2:01 PM, John Ford wrote:

  Hi, John,
 
  The benchmarking tests were done here by Christopher Schollar who was
  visiting from the University of Cape Town.  I'm not sure which library
  version he used, but I can find out.
 
  It was mostly just curiosity on my part, but are you using the same
  blocks
  for your work?
 
  John
 
 
 
  Dave
 
  On Feb 13, 2013, at 1:30 PM, John Ford wrote:
 
  Hi, Rich,
 
  We've sustained 9.9 Gpbs simultaneously from two 10 GbE ports (19.8
  Gbps
  aggregate) on a ROACH into a PC with two 10 GbE NICs without dropping
  any
  packets.  This was direct connect (i.e. no switch) and transmit
  only
  (i.e. no packets were sent back to the ROACH).
 
 
  Rich, Dave, can you tell us the versions of the libraries you have?
 
  Thanks!
 
  John
 
  Hope this helps,
  Dave
 
  On Feb 13, 2013, at 1:06 PM, Rich Lacasse wrote:
 
  Hi All,
 
  Using the latest 10 GbE yellow block, has anyone achieved a
  sustained
  data rate of greater than 8 Gb/s?
 
  Thanks,
  Rich
 
 
 
 
 
 
 
 
 
 

Re: casper-scm Recent mlib_devel pushes to casper-astro

[G Jones]

I think this is a good idea anyway, since the undoing bunch of
commits message was to restore iBOB + BEE2. So I think it's natural
to have a branch in the library.

On Tue, Feb 12, 2013 at 2:35 PM, Jason Manley jasonman...@gmail.com wrote:
 Sorry Dave! The updates all happened when we updated all the tutorials for 
 our recent workshop. There should have been more consultation.

 If 14.x is breaking backwards compatibly, maybe we should freeze mlib_devel 
 as mlib_11.x as we did with the old v7.1 blocks when we moved to 11.x. It 
 would then be up to 11.x users to backport/cherry-pick from the development 
 branch.

 I'm afraid we don't have the capacity to maintain multiple versions and 
 SKA-SA's firmly on the 14.x + 2012b flow.

 Jason



 On 12 Feb 2013, at 21:12, David MacMahon wrote:

 What's going on with recent mlib_devel pushes to casper-astro?  Why so much 
 activity from our South African friends there instead of in the ska-sa 
 repository?  Why the lack of any discussion (e.g. on this list) about this?

 I fetched from casper-astro on January 24th and got commit 9940104, but now 
 I see  that 18 cherry picked commits and an Undoing bunch of commits 
 commit have been pushed to casper-astro since then.  It's really hard to 
 tell what's going on there.

 I dislike commit 2df7b03 (cherry picked from f22a98c) that puts 14.2 into 
 system.xmp for the sole purpose of avoiding a rev-up when building.  That 
 may save 14.2 users a few seconds off their hours long build, but it forces 
 every ROACH2 user to upgrade to 14.2.  Do we really want to mandate that 
 users get 14.2 if they want to do ROACH2 development?  Not everyone gets 
 donations and/or free upgrades of the toolflow software.

 Thanks,
 Dave

Re: [casper] ADC1X5000-8 correlator question

[G Jones]

Hi Ross,
One point to clarify, the 5000 refers to the samping rate, not the
total bandwidth. So a single ADC1X5000 demux 1:2 will give you 5000
Msps at 4 bits per sample, allowing you to sample signals up to 2.5
GHz bandwidth. With a single board, you'd need to put the board in the
mode that instead acts as two ADCs each providing 2500 Msps at 4 bits
per sample, hence you'd be able to correlate two signals each of up to
1.25 GHz bandwidth. With two ADC cards, you could correlate two 2.5
GHz BW signals.

Glenn

On Tue, Feb 12, 2013 at 3:53 PM, Ross Williamson
rwilliam...@astro.caltech.edu wrote:
 Hi All,

 I'm new to CASPER/ROACH boards and so apologies if this is obvious.  We are
 hoping to build a simple 2-channel correlator  with a fairly high bandwidth.
 We are in the process of ordering a ROACH-1 board and I was thinking of also
 purchasing the ADC1X5000-8 ADC - A few questions:

 1) Should I even be looking at an ADC1X5000-8 for use as a correlator?
 2) I believe I need the DMUX 1:2 version to work with ROACH-1 board - is
 that correct?
 3) I should be able to run 2 channels at 2.5GHz 4bits with a single board -
 correct?
 4) If I wanted to could I purchase another ADC1X5000-8 and try and run with
 5GHz bandwidth on each channel using the ROACH-1?

 Best regards,

 Ross

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

Re: [casper] QDR on ROACH vs ROACH2

[G Jones]

I'm pretty sure they're twice as wide to keep up with the increased
processing throughput possible with the bigger FPGA.

On Tue, Feb 5, 2013 at 3:10 PM, David MacMahon
dav...@astro.berkeley.edu wrote:
 When I place a QDR yellow block in a ROACH model, the data out port is 36 
 bits wide.  In a ROACH2 model, the QDR data out port is 72 bits wide.  The 
 data in port seems to double in expected width as well on ROACH2 as 
 compared to ROACH.

 Why the dramatic interface change for ROACH2?  Are the data ports on the 
 ROACH2 QDR chips really twice as wide as on the ROACH QDR chips or has the 
 QDR use pattern changed for ROACH2 or ???

 Thanks,
 Dave

[casper] tcpborphserver3 failure in tg.c

[G Jones]

Hi,
As mentioned previously, we've been noticing failures of
tcpborphserver3 at a rate that has become annoying enough to finally
track down. We compiled from the github source on the ROACH2 itself
with debugging enabled and ran through gdb. The failure results are
described below. The problem seems to occur during the starttap
command. We'll forward along the raw katcp command we're using, but
the curious thing is why base which comes from:

base = gs-s_raw_mode-r_map + gs-s_register-e_pos_base;

is pointing to invalid memory sometimes.

Any ideas?
Thanks,
Glenn and Ray

-- Forwarded message --
From: Ramon E. Creager rcrea...@nrao.edu
Date: Tue, Jan 29, 2013 at 3:09 PM
Subject: [Gbsapp] tcpborphserver3 failure in tg.c


I've gotten the tcpborphserver to fail under the debugger, but because I
don't yet understand the memory management used in this program I'm not
yet sure what the problem is, so I'm putting this out in case someone
who understands the tcpborphserver can help isolate the problem more
quickly than I can.  The segv occurs in tg.c, line 421.  The gdb output is:

Program received signal SIGSEGV, Segmentation fault.
0x100092d4 in write_mac_fpga (gs=0x107b7928, offset=0, mac=0x107b7970
\002\002\n\021) at tg.c:421
421   *((uint32_t *)(base + offset)) = value;
(gdb) where
#0  0x100092d4 in write_mac_fpga (gs=0x107b7928, offset=0,
mac=0x107b7970 \002\002\n\021) at tg.c:421
#1  0x1000a140 in configure_fpga (gs=0x107b7928) at tg.c:877
#2  0x1000ae68 in create_getap (d=0x107878b8, instance=0,
name=0x10795da0 gbe0, tap=0x10795d9b tap0,
ip=0x10795da5 10.17.0.65, port=6, mac=0x10795db6
02:02:0A:11:00:41, period=10) at tg.c:1167
#3  0x1000b258 in insert_getap (d=0x107878b8, name=0x10795da0 gbe0,
tap=0x10795d9b tap0,
ip=0x10795da5 10.17.0.65, port=6, mac=0x10795db6
02:02:0A:11:00:41, period=10) at tg.c:1230
#4  0x1000b514 in tap_start_cmd (d=0x107878b8, argc=6) at tg.c:1290
#5  0x100143bc in call_katcp (d=0x107878b8) at dispatch.c:879
#6  0x100145cc in dispatch_katcp (d=0x107878b8) at dispatch.c:951
#7  0x10018994 in run_shared_katcp (d=0x10782008) at shared.c:659
#8  0x1001cbe8 in run_core_loop_katcp (dl=0x10782008) at server.c:699
#9  0x1001d0c0 in run_config_server_katcp (dl=0x10782008, file=0x0,
count=32, host=0x10047c90 7147, port=0)
at server.c:832
#10 0x10002034 in main (argc=3, argv=0xbff188f4) at main.c:196
(gdb) frame 1
#1  0x1000a140 in configure_fpga (gs=0x107b7928) at tg.c:877
877   if(write_mac_fpga(gs, GO_MAC, gs-s_mac_binary)  0){
(gdb) frame 0
#0  0x100092d4 in write_mac_fpga (gs=0x107b7928, offset=0,
mac=0x107b7970 \002\002\n\021) at tg.c:421
421   *((uint32_t *)(base + offset)) = value;
(gdb) list
416
417   value = (   0x0  0xff00) |
418   (   0x0  0xff) |
419   ((mac[0]   8)  0xff00) |
420(mac[1] 0xff);
421   *((uint32_t *)(base + offset)) = value;
422
423
424   value = ((mac[2]  24)  0xff00) |
425   ((mac[3]  16)  0xff) |
(gdb) print base
$1 = (void *) 0x1033fff
(gdb) print offset
$2 = 0
(gdb) print value
$3 = 514
(gdb)

'base' is a void * which is set like this:
 base = gs-s_raw_mode-r_map + gs-s_register-e_pos_base;
(back to gdb):

(gdb) print *(gs-s_raw_mode)
$12 = {r_registers = 0x10783d80, r_hwmon = 0x10783d90, r_fpga = 1, r_map
= 0x, r_map_size = 33554432,
  r_image = 0x0, r_bof_dir = 0x10783da0 /boffiles, r_top_register =
17314052, r_argc = 3,
  r_argv = 0xbff188f4, r_chassis = 0x107876e0, r_taps = 0x10785820,
r_instances = 0}
(gdb) print *(gs-s_register)
$13 = {e_pos_base = 16990208, e_len_base = 16384, e_pos_offset = 0
'\000', e_len_offset = 0 '\000',
  e_mode = 3 '\003'}
(gdb)


I should add that 'base' is pointing to memory gdb says it cannot access
(hence the segv):

(gdb) print *(uint32_t *)base
Cannot access memory at address 0x1033fff


Ray

Re: [casper] tcpborphserver3 failure in tg.c

[G Jones]

The katcp command was:

?tap-start tap0 gbe0 10.17.0.65 6 02:02:0A:11:00:41

On Tue, Jan 29, 2013 at 3:42 PM, G Jones glenn.calt...@gmail.com wrote:
 Hi,
 As mentioned previously, we've been noticing failures of
 tcpborphserver3 at a rate that has become annoying enough to finally
 track down. We compiled from the github source on the ROACH2 itself
 with debugging enabled and ran through gdb. The failure results are
 described below. The problem seems to occur during the starttap
 command. We'll forward along the raw katcp command we're using, but
 the curious thing is why base which comes from:

 base = gs-s_raw_mode-r_map + gs-s_register-e_pos_base;

 is pointing to invalid memory sometimes.

 Any ideas?
 Thanks,
 Glenn and Ray

 -- Forwarded message --
 From: Ramon E. Creager rcrea...@nrao.edu
 Date: Tue, Jan 29, 2013 at 3:09 PM
 Subject: [Gbsapp] tcpborphserver3 failure in tg.c


 I've gotten the tcpborphserver to fail under the debugger, but because I
 don't yet understand the memory management used in this program I'm not
 yet sure what the problem is, so I'm putting this out in case someone
 who understands the tcpborphserver can help isolate the problem more
 quickly than I can.  The segv occurs in tg.c, line 421.  The gdb output is:

 Program received signal SIGSEGV, Segmentation fault.
 0x100092d4 in write_mac_fpga (gs=0x107b7928, offset=0, mac=0x107b7970
 \002\002\n\021) at tg.c:421
 421   *((uint32_t *)(base + offset)) = value;
 (gdb) where
 #0  0x100092d4 in write_mac_fpga (gs=0x107b7928, offset=0,
 mac=0x107b7970 \002\002\n\021) at tg.c:421
 #1  0x1000a140 in configure_fpga (gs=0x107b7928) at tg.c:877
 #2  0x1000ae68 in create_getap (d=0x107878b8, instance=0,
 name=0x10795da0 gbe0, tap=0x10795d9b tap0,
 ip=0x10795da5 10.17.0.65, port=6, mac=0x10795db6
 02:02:0A:11:00:41, period=10) at tg.c:1167
 #3  0x1000b258 in insert_getap (d=0x107878b8, name=0x10795da0 gbe0,
 tap=0x10795d9b tap0,
 ip=0x10795da5 10.17.0.65, port=6, mac=0x10795db6
 02:02:0A:11:00:41, period=10) at tg.c:1230
 #4  0x1000b514 in tap_start_cmd (d=0x107878b8, argc=6) at tg.c:1290
 #5  0x100143bc in call_katcp (d=0x107878b8) at dispatch.c:879
 #6  0x100145cc in dispatch_katcp (d=0x107878b8) at dispatch.c:951
 #7  0x10018994 in run_shared_katcp (d=0x10782008) at shared.c:659
 #8  0x1001cbe8 in run_core_loop_katcp (dl=0x10782008) at server.c:699
 #9  0x1001d0c0 in run_config_server_katcp (dl=0x10782008, file=0x0,
 count=32, host=0x10047c90 7147, port=0)
 at server.c:832
 #10 0x10002034 in main (argc=3, argv=0xbff188f4) at main.c:196
 (gdb) frame 1
 #1  0x1000a140 in configure_fpga (gs=0x107b7928) at tg.c:877
 877   if(write_mac_fpga(gs, GO_MAC, gs-s_mac_binary)  0){
 (gdb) frame 0
 #0  0x100092d4 in write_mac_fpga (gs=0x107b7928, offset=0,
 mac=0x107b7970 \002\002\n\021) at tg.c:421
 421   *((uint32_t *)(base + offset)) = value;
 (gdb) list
 416
 417   value = (   0x0  0xff00) |
 418   (   0x0  0xff) |
 419   ((mac[0]   8)  0xff00) |
 420(mac[1] 0xff);
 421   *((uint32_t *)(base + offset)) = value;
 422
 423
 424   value = ((mac[2]  24)  0xff00) |
 425   ((mac[3]  16)  0xff) |
 (gdb) print base
 $1 = (void *) 0x1033fff
 (gdb) print offset
 $2 = 0
 (gdb) print value
 $3 = 514
 (gdb)

 'base' is a void * which is set like this:
  base = gs-s_raw_mode-r_map + gs-s_register-e_pos_base;
 (back to gdb):

 (gdb) print *(gs-s_raw_mode)
 $12 = {r_registers = 0x10783d80, r_hwmon = 0x10783d90, r_fpga = 1, r_map
 = 0x, r_map_size = 33554432,
   r_image = 0x0, r_bof_dir = 0x10783da0 /boffiles, r_top_register =
 17314052, r_argc = 3,
   r_argv = 0xbff188f4, r_chassis = 0x107876e0, r_taps = 0x10785820,
 r_instances = 0}
 (gdb) print *(gs-s_register)
 $13 = {e_pos_base = 16990208, e_len_base = 16384, e_pos_offset = 0
 '\000', e_len_offset = 0 '\000',
   e_mode = 3 '\003'}
 (gdb)


 I should add that 'base' is pointing to memory gdb says it cannot access
 (hence the segv):

 (gdb) print *(uint32_t *)base
 Cannot access memory at address 0x1033fff


 Ray

Re: [casper] ROACH 2 ARP

[G Jones]

Looking through the tcpborphserver3 code, I saw there is a tap-info
command. When I run that I get:

?tap-info
#log info 2212751 raw peer\_10:10:10:10:10:11\_at\_18000
#log info 2212751 raw peer\_02:02:0a:11:00:40\_at\_0
#log info 2212751 raw current\_iteration\_0
#log info 2212751 raw buffers\_arp=0/rx=0/tx=0
#log info 2212751 raw polling\_interval\_10
#log info 2212751 raw address\_10.17.0.64
#log info 2212751 raw gateware\_port\_is\_6
#log info 2212751 raw tap\_device\_name\_tap0\_on\_fd\_29
!tap-info ok

The 10:10:10 MAC is a BEE2 on the network happily blasting arps as
usual, and the 02:02:0A... MAC is this ROACH2 itself. So it seems like
it is receiving and interpreting ARPs OK. It's just not sending them
itself...

Any ideas?

Thanks,
Glenn

On Tue, Dec 18, 2012 at 10:58 AM, G Jones glenn.calt...@gmail.com wrote:
 Hi,
 In the last couple of days our ROACH2's have decided to stop sending
 ARP packets after tapstart'ing. As a result, the default ARP table
 values cause all UDP packets to be sent to the broadcast MAC address
 (all F's). Any ideas what could have caused this and how to fix it? My
 best guess is that we changed uImage files a while ago to try to deal
 with the TBS3 write/wordwrite bug and perhaps the ROACH2's weren't
 rebooted until later so we didn't see the change until recently. But
 I'm not sure.

 The tge details look fine:
 
 GBE0 Configuration...
 My MAC:  02 02 0A 11 00 40
 Gateway:0   0   0   1
 This IP:   10  17   0  64
 Gateware Port:  6
 Fabric interface is currently:  Enabled
 XAUI Status:  007E
  lane sync 0: 1
  lane sync 1: 1
  lane sync 2: 1
  lane sync 3: 1
  Channel bond: 1
 XAUI PHY config:
 RX_eq_mix:  A
 RX_eq_pol:  4
 TX_pre-emph:  0
 TX_diff_ctrl:  7


 Thanks,
 Glenn

Re: [casper] ROACH 2 ARP

[G Jones]

Correction: this is indeed a problem, but my description is not quite
correct. It seems the poll interval is 10 ms and the burst logic
looks to see if there's more than one packet in a poll inteval. The
BEE2 on the network is sending ARP packets every ~4ms so a burst is
perpetually detected. So I need to increase the number of packets per
poling itnerval to count as a burst.
I'm just going to disable the burst checking for now.

Glenn

On Tue, Dec 18, 2012 at 2:08 PM, G Jones glenn.calt...@gmail.com wrote:
 Well I think I located the problem:
 in tcpborphserver3/tg.c
 The main do-while loop has a burst variable that's supposed to keep
 the ROACH from broadcasting ARPs if the network is busy. burst is
 initialized to zero at the start of the program, but from that point
 on, it is only incremented. The ARP spamming as it's called only
 occurs if burst  1, so once a burst is detected, it will never
 again spam ARP packets. In our case, the network is being spammed by
 the BEE2 on the net and other devices, so it never gets a chance to do
 it's ARP broadcast.

 I'll try to fix this myself, but someone more familiar with the code
 should look at it and decide what the right thing to do is.

 Glenn

 On Tue, Dec 18, 2012 at 1:57 PM, G Jones glenn.calt...@gmail.com wrote:
 Looking through the tcpborphserver3 code, I saw there is a tap-info
 command. When I run that I get:

 ?tap-info
 #log info 2212751 raw peer\_10:10:10:10:10:11\_at\_18000
 #log info 2212751 raw peer\_02:02:0a:11:00:40\_at\_0
 #log info 2212751 raw current\_iteration\_0
 #log info 2212751 raw buffers\_arp=0/rx=0/tx=0
 #log info 2212751 raw polling\_interval\_10
 #log info 2212751 raw address\_10.17.0.64
 #log info 2212751 raw gateware\_port\_is\_6
 #log info 2212751 raw tap\_device\_name\_tap0\_on\_fd\_29
 !tap-info ok

 The 10:10:10 MAC is a BEE2 on the network happily blasting arps as
 usual, and the 02:02:0A... MAC is this ROACH2 itself. So it seems like
 it is receiving and interpreting ARPs OK. It's just not sending them
 itself...

 Any ideas?

 Thanks,
 Glenn

 On Tue, Dec 18, 2012 at 10:58 AM, G Jones glenn.calt...@gmail.com wrote:
 Hi,
 In the last couple of days our ROACH2's have decided to stop sending
 ARP packets after tapstart'ing. As a result, the default ARP table
 values cause all UDP packets to be sent to the broadcast MAC address
 (all F's). Any ideas what could have caused this and how to fix it? My
 best guess is that we changed uImage files a while ago to try to deal
 with the TBS3 write/wordwrite bug and perhaps the ROACH2's weren't
 rebooted until later so we didn't see the change until recently. But
 I'm not sure.

 The tge details look fine:
 
 GBE0 Configuration...
 My MAC:  02 02 0A 11 00 40
 Gateway:0   0   0   1
 This IP:   10  17   0  64
 Gateware Port:  6
 Fabric interface is currently:  Enabled
 XAUI Status:  007E
  lane sync 0: 1
  lane sync 1: 1
  lane sync 2: 1
  lane sync 3: 1
  Channel bond: 1
 XAUI PHY config:
 RX_eq_mix:  A
 RX_eq_pol:  4
 TX_pre-emph:  0
 TX_diff_ctrl:  7


 Thanks,
 Glenn

[casper] Access to ROACH 2 10 GbE ARP table from PPC?

[G Jones]

Hi,
Is it possible to access the ARP table from the PPC on ROACH2? I'd
like to see what entries it contains and if possible populate it.

Thanks,
Glenn

Re: [casper] snapshot block with external trigger

[G Jones]

So far, the wordwrite workaround does not appear to be working for me, but
I'm still investigating.
Glenn

On Mon, Dec 10, 2012 at 2:12 PM, Alec Rust alec.r...@ska.ac.za wrote:

 Dave if the wordwrite workaround works lets stick to that for now. The
 workaround Marc compiled is not really good for release. We'll work on a
 proper release but for now use wordwrite if thats ok?

 Regards
 Alec


 On Mon, Dec 10, 2012 at 8:42 PM, David MacMahon dav...@astro.berkeley.edu
  wrote:

 Hi, Marc,

 I can confirm that the wordwrite workaround works.  Hopefully the fix for
 byte enables (either to make tcpborphserver3 not use them or to make the
 gateware support them) will not be too hard.

 Thanks,
 Dave

 On Dec 10, 2012, at 7:06 AM, Marc Welz wrote:

  Hello
 
  We have picked up on transient on the register write with the latest
 memory
  mapped TCPBORPH. It seems that sometimes, some of the bits goes high
 for a
  short while and then settles at the required register value.
 
  We need to figure out where the issue is (gateware or software).
 
  So we think we have found the problem - ?write operations in
  tcpborphserver3 rely on byte enables, which are not supported by the
  gateware. I'll rewrite ?write to use multiples of 4... but in the mean
  time you
  could try using ?wordwrite, which operates on words, and so doesn't use
 byte
  enables. That workardound should be simpler than installing older
  kernel/tcpborphserver combinations.
 
  regards
 
  marc