Re: [casper] unable to run tcpborphserver2 from the command line
Thanks Marc, No, the *only* difference between being able to program the fpga with 'progdev' is whether or not I'm running tcpborphserver2 from the command-line, or whether it is running from when the board booted up. It makes no difference what bof I use. Paul On 02/25/2015 02:46 AM, Marc Welz wrote: ?progdev mba15_obs2d_2014_Jan_31_1052.bof So this is the same bof file which sometimes works and sometimes does not ? Or is this subsequent to some upgrade of the roach ? If it is a sometimes work/not work issue maybe you are not marking it executable (chmod +x) on transfer or the transfer is garbled. If it is subsequent to an upgrade: Note that at some point we moved to a different kernel+driver+tcpborphserver combination, which uses a mmap interface - if you change to that you will have to update both kernel and tcpborphserver, but for roach1 this is a backport, so probably something for experts ... regards marc
Re: [casper] unable to run tcpborphserver2 from the command line
Thanks Marc, I tracked down where it is being called from linux startup, and it didn't look like any options were being passed, so I ignored this issue for a while. I then tried it once with the -b set to /boffiles, and that made no difference. I wasn't sure what the other option values should be other then the defaults. Paul On 02/24/2015 09:25 AM, Marc Welz wrote: On Tue, Feb 24, 2015 at 12:22 PM, Paul Marganian pmarg...@nrao.edu mailto:pmarg...@nrao.edu wrote: Hi everyone, I've recently run in to a problem with tcpborphserver2 running on Roach 1. In the past, I've been able to debug and develop simply by running this program interactively, getting feedback from print statements. Recently, I've seen that when I run this program from the command line, the 'progdev' command fails. Has anyone else seen this behavior? thanks Paul Marganian Are you running it with the correct options, in particular the one which points it at the correct bof file directory ? regards marc
Re: [casper] unable to run tcpborphserver2 from the command line
Thanks Marc, It seems I might have sent you the wrong output? I agree, that output looks like things must have worked. Here's my latest output: ?progdev mba15_obs2d_2014_Jan_31_1052.bof #log debug 2130698889868 roach.mba terminating\_subprocesses\_matching\_type\_1 #log debug 2130698889868 roach.mba 0\_terminated\_processes\_need\_to\_be\_collected #log trace 2130698889869 roach.mba attempting\_to\_terminate\_child\_process\_borph #log debug 2130698889870 roach.mba 0\_terminated\_processes\_need\_to\_be\_collected #log debug 2130698889870 roach.mba system\_deprogrammed #log debug 2130698889870 roach.mba attempting\_to\_program\_/boffiles/mba15_obs2d_2014_Jan_31_1052.bof #log error 2130698920112 roach.mba timed\_out\_while\_waiting\_for\_fpga\_status\_to\_change:\_No\_such\_file\_or\_directory #log warn 2130698920115 roach.mba timed\_out\_while\_waiting\_for\_status\_register,\_but\_returning\_ok\_because\_ioreg\_exists #log warn 2130698920117 roach.mba collected\_process\_id\_589\_with\_status\_0x4700 #log warn 2130698920120 roach.mba borph\_process\_exited #log warn 2130698920122 roach.mba borph\_exited,\_but\_no\_image\_to\_clear #log fatal 2130698920124 roach.mba unable\_to\_program\_gateware !progdev fail program On 02/24/2015 02:09 PM, Mar Hello Thanks Marc, Good suggestion. I'd hat the log level set to debug, but hadn't thought of lowering it. I get a lot of output, most of which I don't quite understand (see below). At this point, I probably should add that we are running a tcpborphserver with a mode we created for our own system, 'mba': So ?progdev mba15_obs2d_2014_Jan_31_1052.bof ... !progdev ok 537 the !progdev ok suggests that it managed to program the FPGA successfully - there should be a borph process with pid 537 running - you should now be able to read/write the registers ? #log error 151615780430 roach.mba timed\_out\_while\_waiting\_for\_fpga\_status\_to\_change:\_No\_such\_file\_or\_directory This I think relates to a particular status register which certain revisions of the gateware supplied to show if the programming completed - it is unclear if this is even a problem in your case, but I probably don't the details completely. What matters is if you can see the registers then the programming should have worked out - if you type ?listdev you can check your register set, if that disappears after a short while then you might have problems with the elf executable embedded in your .bof file regards marc
Re: [casper] KATCP clients not connecting
If you're using the python module 'corr', you can increase the default timeout for establishing the connection. For example: import corr r = corr.katcp_wrapper.FpgaClient(roachIP, roachPort, timeout=60) On 12/15/2014 05:53 PM, Michael D'Cruze wrote: Hi Ross, OK thanks for that, I plan to give that a try tomorrow. Any ideas about Corr? Corr seems the more promising route. BW Michael -Original Message- From: Ross Williamson [mailto:rwilliam...@astro.caltech.edu] Sent: 15 December 2014 22:51 To: Michael D'Cruze Cc: casper@lists.berkeley.edu Subject: Re: [casper] KATCP clients not connecting Hi Michael, The MATLAB katcp is very very old. If you look you will see that it looking for a response from tcpborphserver that it no longer sends - You need to hack the katcp.m file to match what the server is currently sending Ross On Mon, Dec 15, 2014 at 1:50 PM, Michael D'Cruze michael.dcr...@postgrad.manchester.ac.uk wrote: Hi everyone I’m trying to connect to the board using the Corr and Matlab katcp clients, however through both the connection times out. I think I have all the python libraries installed, and I definitely have the ICT toolbox installed in Matlab. I’ve tried disabling the firewall. Katcp does work through telnet…. Has anybody seen this issue before? Is there something I’m missing? Very grateful for any suggestions. Michael PS (possibly related problem): I installed Anaconda after this (thought Corr might not like RHEL6.x’s standard python 2.6.6) to bring my python and packages up-to-date and into sync, but katcp wouldn’t then reinstall to the new version. It was complaining of missing setuptools, but in conda I had version 7.0 installed, and there was definitely some version installed in RHEL’s python as well…. If it won’t install full-stop I’ll just get rid of Anaconda but again if anyone’s seen this issue before and has any suggestions please pass them along J. -- Ross Williamson Research Scientist - Sub-mm Group California Institute of Technology 626-395-2647 (office) 312-504-3051 (Cell)
[casper] finding the pid of the bof process on roach2
I would like to use some of the same methods I learned in the casper tutorial: https://casper.berkeley.edu/wiki/Introduction_to_Simulink on roach 2, including finding the pid of my bof process and navigating to it's proc directory. However, though this works on roach 1, on roach 2 I can't seem to find my bof process using ps aux, nor the pidof command. What am I missing? thanks Paul Marganian NRAO Green Bank
Re: [casper] How to set the sys_rev, sys_rev_rcs, and sys_scratchpad registers?
Thanks everyone! I'll give that a try. Paul On 02/26/2014 10:16 AM, Jason Manley wrote: The RCS stuff is set by dragging the RCS block from the library into the top level of your design (next to System Generator block). Double-click and set the mask parameters as normal. It will try'n pull the git revisions of your mlib library and model file for you automatically when you compile, if you're working from valid git checkouts. Failing that, it will use timestamps. This is handled automatically with the get_rcs function in corr. Jason On 26 Feb 2014, at 17:07, Jack Hickish jackhick...@gmail.com wrote: Hi Paul, None of these registers is directly configurable from within simulink. They live in the sys_block pcore -- see the relevant base package .../xps_base/XPS_ROACHx_base/system.mhs, for where their values are set. The sys_rev and sys_rev_rcs are determined by the hardware. E.g., roach has board id 0xb00b and roach2 0xbabe. I don't know quite how the rest of the version information is encoded in the registers, but in principal if you set the parameters of the sys_block accordingly, you can set the values of those registers to whatever you like. sys_scratchpad is a blank read/writable register for testing the power pc interface -- it doesn't have any direct interface to your simulink design, so you can't write to it from your model. Cheers, Jack On 26 February 2014 14:38, Paul Marganian pmarg...@nrao.edu wrote: Can anyone tell me how to set the sys_rev, sys_rev_rcs, and sys_scratchpad registers from within my model? Thanks Paul Marganian NRAO, Green Bank
Re: [casper] Simulating Shared BRAM
Tim, There may be a better solution, but I would try using the 'gateway out' block to a 'To Workspace' block. Then you can examine that variable in your matlab workspace. Hope this helps, Paul On 02/18/2014 05:26 PM, Madden, Timothy J. wrote: Folks This is probably a question asked before, but I am simulating a model and storing data to a shared BRAM. Is there a way to view the contents of what was written to the BRAM during the simulation? Tim
Re: [casper] Timing errors and subsystems
On 01/30/2014 07:33 AM, Jack Hickish wrote: Hi Paul, I believe the placement cost table is the parameter you want to change (See http://www.xilinx.com/support/answers/35534.html). You should be able to change this and other compile parameters in xps_base/XPS_ROACH[2]_base/etc/fast_runtime.opt Thanks Jack! There's a lot for me there to sink my teeth into. I'll check it out. I did a few more experiments which I believe confirms what you've been telling me: * changing a subsystem name changes results * replacing an edge with gotos does *not* cause changes * adding a random comment does *not* cause changes You might find that you get on better changing the effort/optimization settings than the starting placer cost table. I'd be interested to hear any changes which you find particularly useful. FWIW, I would just import a compile into planahead, and vary the options from there. Then you can save the different strategies and keep track of which ones work (and have a nice gui to tell you what the options actually do). You can also spawn multiple compiles with different options (on multiple servers, if you have them), for when things get *really* desperate... I've toyed with Planahead a bit, and quickly found I was in way over my head. Could you recommend a good starting point for learning this tool? Cheers, Jack On 30 January 2014 11:57, Paul Marganian pmarg...@nrao.edu wrote: Thanks Jack and John, Yes, wtf was certainly the first TLA that came to mind :) Well, I took my test model and changed the name of a subsystem, and after compiling, the number of timing errors went from 153 to 151. Obviously not a significant change, but the mere fact that they changed at all lends me to believe that the algorithm's start seed has indeed been changed. Is this seed at all exposed in any of the configuration files? In other words, is there a way to roll the dice and see if you can get a better timing score by simply changing this seed and compiling again? Thanks for your help, Paul On 01/29/2014 06:07 PM, Jack Hickish wrote: I'm not sure what, if any, difference a subsystem will make to the mapped design (I thought none), but I believe it's the case that changing module names etc. can affect the place and route algorithm's start seed. I seem to remember seeing this mentioned in a Xilinx doc under the heading I've saved my project under a different name, now it won't meet timing, wtf?! On 29 January 2014 22:44, John Ford jf...@nrao.edu wrote: On 01/29/2014 01:03 PM, Paul Marganian wrote: Hi all, Should such software (simulink) features as subsystems and and gotos have any affect on the final circuit created when I build my bof file? I am compiling models on Roach I that use almost all of the available Logic Slices (~97%). That the subsequent build should contain timing errors is not a surprise, but I recently noted a change in my timing errors that puzzled me. I have assumed up till now that certain types of features in my model are superficial, and will not change how the bof file is built. I wanted to test this theory, and rebuilt my model after selecting part of my model and turning it into a subsystem. I was surprised to see that this new build had very different timing errors then the previous one (from 18 errors to just 3). Is it the subsystem that caused this change, or is another one of my assumptions, that timing errors are deterministic and can be reproduced with subsequent builds of identical models, false? I've made a test of this, and indeed, I think my assumption is correct: I get the same timing errors after two subsequent builds. Try saving the model and compiling it again, just changing a comment or something else non-substantive. John thanks Paul Marganian NRAO, Green Bank
Re: [casper] Timing errors and subsystems
wow. Thanks a lot Jack! Paul On 01/30/2014 10:15 AM, Jack Hickish wrote: I've toyed with Planahead a bit, and quickly found I was in way over my head. Could you recommend a good starting point for learning this tool? I'm sure you've found the planahead user guide, which is a bit of a documentation behemoth, but useful if you have a vague idea of what setting you're trying to change and just want to find the right thing to click. There's a reasonable quick intro here -- http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/PlanAhead_Tutorial_Quick_Front-to-Back_Overview.pdf And in general a bunch of tutorials: http://www.xilinx.com/support/index.html/content/xilinx/en/supportNav/design_tools/planahead.html A couple of potentially handy methodology guides are also available for floorplanning: http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/Floorplanning_Methodology_Guide.pdf And planahead in general: http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/PlanAhead_Methodology_Guide_11_1.pdf (there's probably a more up to date version of this but i haven't stumbled on it yet) These are all much shorter than the full user guide, and might help give a better overview of what's going on. Ryan Monroe also wrote a summary of some work he did to optimize a ROACH2 design which he posted on the maillist a while ago: https://dl.dropboxusercontent.com/u/2832602/roach2_timing.zip And there's a very brief overview on the wiki -- https://casper.berkeley.edu/wiki/Speed_Optimization_with_PlanAhead I think some combination of these documents and experimentation is probably as good a start as any. I'd recommend starting with the planahead overview, and go from there [with the caveat that I count myself only marginally proficient with planahead, so ymmv]. Good luck! Jack Cheers, Jack On 30 January 2014 11:57, Paul Marganian pmarg...@nrao.edu wrote: Thanks Jack and John, Yes, wtf was certainly the first TLA that came to mind :) Well, I took my test model and changed the name of a subsystem, and after compiling, the number of timing errors went from 153 to 151. Obviously not a significant change, but the mere fact that they changed at all lends me to believe that the algorithm's start seed has indeed been changed. Is this seed at all exposed in any of the configuration files? In other words, is there a way to roll the dice and see if you can get a better timing score by simply changing this seed and compiling again? Thanks for your help, Paul On 01/29/2014 06:07 PM, Jack Hickish wrote: I'm not sure what, if any, difference a subsystem will make to the mapped design (I thought none), but I believe it's the case that changing module names etc. can affect the place and route algorithm's start seed. I seem to remember seeing this mentioned in a Xilinx doc under the heading I've saved my project under a different name, now it won't meet timing, wtf?! On 29 January 2014 22:44, John Ford jf...@nrao.edu wrote: On 01/29/2014 01:03 PM, Paul Marganian wrote: Hi all, Should such software (simulink) features as subsystems and and gotos have any affect on the final circuit created when I build my bof file? I am compiling models on Roach I that use almost all of the available Logic Slices (~97%). That the subsequent build should contain timing errors is not a surprise, but I recently noted a change in my timing errors that puzzled me. I have assumed up till now that certain types of features in my model are superficial, and will not change how the bof file is built. I wanted to test this theory, and rebuilt my model after selecting part of my model and turning it into a subsystem. I was surprised to see that this new build had very different timing errors then the previous one (from 18 errors to just 3). Is it the subsystem that caused this change, or is another one of my assumptions, that timing errors are deterministic and can be reproduced with subsequent builds of identical models, false? I've made a test of this, and indeed, I think my assumption is correct: I get the same timing errors after two subsequent builds. Try saving the model and compiling it again, just changing a comment or something else non-substantive. John thanks Paul Marganian NRAO, Green Bank
[casper] Timing errors and subsystems
Hi all, Should such software (simulink) features as subsystems and and gotos have any affect on the final circuit created when I build my bof file? I am compiling models on Roach I that use almost all of the available Logic Slices (~97%). That the subsequent build should contain timing errors is not a surprise, but I recently noted a change in my timing errors that puzzled me. I have assumed up till now that certain types of features in my model are superficial, and will not change how the bof file is built. I wanted to test this theory, and rebuilt my model after selecting part of my model and turning it into a subsystem. I was surprised to see that this new build had very different timing errors then the previous one (from 18 errors to just 3). Is it the subsystem that caused this change, or is another one of my assumptions, that timing errors are deterministic and can be reproduced with subsequent builds of identical models, false? thanks Paul Marganian NRAO, Green Bank
Re: [casper] Timing errors and subsystems
On 01/29/2014 01:03 PM, Paul Marganian wrote: Hi all, Should such software (simulink) features as subsystems and and gotos have any affect on the final circuit created when I build my bof file? I am compiling models on Roach I that use almost all of the available Logic Slices (~97%). That the subsequent build should contain timing errors is not a surprise, but I recently noted a change in my timing errors that puzzled me. I have assumed up till now that certain types of features in my model are superficial, and will not change how the bof file is built. I wanted to test this theory, and rebuilt my model after selecting part of my model and turning it into a subsystem. I was surprised to see that this new build had very different timing errors then the previous one (from 18 errors to just 3). Is it the subsystem that caused this change, or is another one of my assumptions, that timing errors are deterministic and can be reproduced with subsequent builds of identical models, false? I've made a test of this, and indeed, I think my assumption is correct: I get the same timing errors after two subsequent builds. thanks Paul Marganian NRAO, Green Bank
[casper] Trouble with Casper DSP sincos block
Hi, I've recently been having problems with the Casper DSP sincos block. I'll successfully run a number of simulations, then I start getting these errors at compile time: Error in 'test_sin/sincos1 matlab:open_and_hilite_system%20%28%27test_sin/sincos1%27%29': Initialization commands cannot be evaluated Error evaluating parameter 'initVector' in 'test_sin/sincos1/rom0 matlab:open_and_hilite_system%20%28%27test_sin/sincos1/rom0%27%29' Subscript indices must either be real positive integers or logicals. The only way to get away from this error seems to be shutting down both the model *and* restarting matlab again. After a few new simulations however, the problem comes back up, slowing down my workflow considerably. Any ideas? I'm running R2012a (7.14.0.739). Thanks Paul Marganian
Re: [casper] Trouble with Casper DSP sincos block
Sorry Andrew, I can't seem to find any of the alternatives you recommended. We're using xlinx 14.3, and our mlib_devel's most recent commit was May of this year. Thanks again, Paul On 09/19/2013 11:41 AM, Paul Marganian wrote: Thanks Andrew, I'll look into those other blocks. The problem happens at compile time. Paul On 09/19/2013 09:45 AM, Andrew Martens wrote: Hi Paul I've recently been having problems with the Casper DSP sincos block. I'll successfully run a number of simulations, then I start getting these errors at compile time: Error in 'test_sin/sincos1 matlab:open_and_hilite_system%20%28%27test_sin/sincos1%27%29': Initialization commands cannot be evaluated Error evaluating parameter 'initVector' in 'test_sin/sincos1/rom0 matlab:open_and_hilite_system%20%28%27test_sin/sincos1/rom0%27%29' Subscript indices must either be real positive integers or logicals. The only way to get away from this error seems to be shutting down both the model *and* restarting matlab again. After a few new simulations however, the problem comes back up, slowing down my workflow considerably. Any ideas? Does the problem only happen at compile time or also during simulation? You can also try the cosin block from the Downconverter subsection. It is more sophisticated in BRAM saving and is used in the FFT library for coefficient generation (so should work). Depending on your application you may also look at using the feedback_osc block which generates a cos/-sin pair using multipliers instead of using a lookup table. It can only generate in-order values though, not in arbitrary order as the sincos/cosin blocks do. The feedback_osc is also used in the fft family so should work. Regards Andrew
Re: [casper] Trouble with Casper DSP sincos block
Great, thanks Dave! I found that block, so I'll take a closer look at it. Paul On 09/19/2013 03:24 PM, David MacMahon wrote: Hi, Paul, Another option would be to use the DDS Compiler block from system generator. That can be used to generate sin/cos signals as well. I'm not sure whether it has all the same options as the CASPER sin/cos block, but could be worth looking into. Hope this helps, Dave On Sep 19, 2013, at 10:26 AM, Paul Marganian wrote: Sorry Andrew, I can't seem to find any of the alternatives you recommended. We're using xlinx 14.3, and our mlib_devel's most recent commit was May of this year. Thanks again, Paul On 09/19/2013 11:41 AM, Paul Marganian wrote: Thanks Andrew, I'll look into those other blocks. The problem happens at compile time. Paul On 09/19/2013 09:45 AM, Andrew Martens wrote: Hi Paul I've recently been having problems with the Casper DSP sincos block. I'll successfully run a number of simulations, then I start getting these errors at compile time: Error in 'test_sin/sincos1': Initialization commands cannot be evaluated Error evaluating parameter 'initVector' in 'test_sin/sincos1/rom0' Subscript indices must either be real positive integers or logicals. The only way to get away from this error seems to be shutting down both the model *and* restarting matlab again. After a few new simulations however, the problem comes back up, slowing down my workflow considerably. Any ideas? Does the problem only happen at compile time or also during simulation? You can also try the cosin block from the Downconverter subsection. It is more sophisticated in BRAM saving and is used in the FFT library for coefficient generation (so should work). Depending on your application you may also look at using the feedback_osc block which generates a cos/-sin pair using multipliers instead of using a lookup table. It can only generate in-order values though, not in arbitrary order as the sincos/cosin blocks do. The feedback_osc is also used in the fft family so should work. Regards Andrew
Re: [casper] Trouble with Casper DSP sincos block
On 09/19/2013 03:14 PM, Andrew Martens wrote: Hi Paul Sorry Andrew, I can't seem to find any of the alternatives you recommended. We're using xlinx 14.3, and our mlib_devel's most recent commit was May of this year. Thanks again Your version of Xilinx should be ok. You may want to do a git pull from casper-astro. Thanks. I'm not sure I'm free to do that, since a number of us are sharing the same environment. But I'll look into it. Can you compile other designs e.g the tutorials? Is the compile problem specific to the sincos block? Yes, it's very specific to this particular block. Regards Andrew On 09/19/2013 11:41 AM, Paul Marganian wrote: Thanks Andrew, I'll look into those other blocks. The problem happens at compile time. Paul On 09/19/2013 09:45 AM, Andrew Martens wrote: Hi Paul I've recently been having problems with the Casper DSP sincos block. I'll successfully run a number of simulations, then I start getting these errors at compile time: Error in 'test_sin/sincos1 matlab:open_and_hilite_system%20%28%27test_sin/sincos1%27%29': Initialization commands cannot be evaluated Error evaluating parameter 'initVector' in 'test_sin/sincos1/rom0 matlab:open_and_hilite_system%20%28%27test_sin/sincos1/rom0%27%29' Subscript indices must either be real positive integers or logicals. The only way to get away from this error seems to be shutting down both the model *and* restarting matlab again. After a few new simulations however, the problem comes back up, slowing down my workflow considerably. Any ideas? Does the problem only happen at compile time or also during simulation? You can also try the cosin block from the Downconverter subsection. It is more sophisticated in BRAM saving and is used in the FFT library for coefficient generation (so should work). Depending on your application you may also look at using the feedback_osc block which generates a cos/-sin pair using multipliers instead of using a lookup table. It can only generate in-order values though, not in arbitrary order as the sincos/cosin blocks do. The feedback_osc is also used in the fft family so should work. Regards Andrew
Re: [casper] one on one
Hi David, I'm certainly not an expert, but I'd be glad to help you get through the first few Casper Tutorials, and I'm right here in Green Bank. Paul Marganian On 08/17/2013 10:42 AM, David Saroff wrote: vCasper folks, Is there any mechanism for the beginner to get one on one time with a CASPER expert? I'm making no headway. Is it me or do the tutorials not compile? A yellow block I need for roach2 exists only for roach1, or am I doing something wrong again? How does the community handle this? The experts where I am are overloaded with work, and can not do the hand holding that I need to get started. I estimate that ~10 hours would be enough, and I would propose to meet for one hour, I watch and take notes, reproduce what the expert has done and retype my notes, and try to make more progress myself for the rest of the day, then meet again for an hour the next day. I could come to you. My desktop computer has all the tools, and I would prefer to use it, who knows, it may not be set up correctly, and that would be the first think to fix. It is luggable. We could skype and screenshare. I use that for teaching remotely one on one. I like the screensharing program TeamViewer. Do novice CASPERites make a pilgrimage to Berkely? Who would I talk to about that? main topics 1) the tutorials that I can't make compile 2) adapting yellow blocks from roach1 to roach2 3) black boxes 4) what I don't know that I don't know that I don't know! Target: a back end for a Greenbank telescope phased array. 38 antennas at the prime focus, in L band separately digitized will be combined and correlated to put 7 or more beams on the sky. Fun! The 64ADC64-12 ADC is being used, with 1 roach1 and 3 roach2's available to process its digitizations. David
