Hi Alec, I'm sorry to say I've kinda run out of suggestions. I can't recreate your problem with my installation. As per my previous email -- with MATLAB 2012b, Xilinx 14.7, and mlib_devel commit 4c7ba5efb4 -- after running update_casper_blocks everything seems to Just Work.
For what it's worth, I'm running Ubuntu 12.04.4, and my startsg.local file looks like: #!/bin/bash ####### User to edit these accordingly ###### export MATLAB_PATH=/opt/MATLAB/R2012b PLATFORM=lin64 export XILINX_PATH=/opt/Xilinx/14.7/ISE_DS export XILINX_PLATFORM=lin64 export MLIB_DEVEL_PATH=/home/jackh/github/mlib_devel2/mlib_devel export TMP=/home/jackh/tmp export TEMP=/home/jackh/tmp export DSP_CACHE_DIR=/home/jackh/tmp ############################################# Cheers Jack On Fri, 2 Dec 2016 at 12:26 Alec Josaitis <josai...@umich.edu> wrote: > Dear Jack, > > I just wanted to follow-up with my last message, about the broken "shared > bram" connections. Any new suggestions? I hope we're close to resolve this > issue, as there are no other errors displayed by MATLAB. Thanks for all the > help you've given, and any more that you may be able to provide! > > Best, > Alec > > On Mon, Nov 21, 2016 at 4:31 PM, Alec Josaitis <josai...@umich.edu> wrote: > > Dear Jack, > > Yes, I ran update_casper_blocks(bdroot), which did not resolve the broken > connections. When I grab a shared bram block directly from my library, the > connections are also broken., same with the sim_munge connections inside > the mem block of each shared bram block (shared bram -> mem ). Further, in > that mem block, there is text which states: "undo data manipulation on way > in and redo on way out for simulated data". I thought about trying to undo > and redo connections as prescribed by this message, but I didn't because I > found a way to resolve all the broken connections, which is described > below. > > Interestingly, I can resolve all of these broken connections (the > shared_bram connections and the mem connections) by literally dragging a > new shared bram library block from my library onto the model diagram > showing the red broken connections, not connecting this just-dragged block > to anything, and then immediately deleting this just-dragged block. After > doing that drag-and-delete step, the previous broken links of the model > become connected. > > Unfortunately, even after performing this drag-and-delete operation by > hand for every shared bram block in either dir_x, I receive the same "|| > and && operator" error described above. > > Any new suggestions? > > Best, > Alec > > On Sat, Nov 19, 2016 at 4:15 PM, Jack Hickish <jackhick...@gmail.com> > wrote: > > Hi Alec, > > And you ran update_casper_blocks(bdroot) after opening your model? > If you grab a new shared bram block from the library, does that really > have the same broken connections? > > Cheers > Jack > > On Fri, 18 Nov 2016 at 13:40 G Jones <glenn.calt...@gmail.com> wrote: > > 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 <josai...@umich.edu> > 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 <josai...@umich.edu> 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 <jackhick...@gmail.com> > 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 <josai...@umich.edu> 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 > <https://casper.berkeley.edu/wiki/Tutorial_Wideband_Pocket_Correlator>. > (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 > <https://github.com/casper-astro/mlib_devel/commit/4c7ba5efb421fda1cec0640cf0e3b830a9987640> > . > > > Best, > Alec > > On Mon, Nov 14, 2016 at 7:52 PM, Jack Hickish <jackhick...@gmail.com> > 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 <josai...@umich.edu> 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 > <https://www.mail-archive.com/casper@lists.berkeley.edu/msg05733.html>, > but there wasn't a clear resolution and I'm not quite sure how to fix this. > This > link > <https://docs.google.com/document/d/19j-WE8WwAo2u_y2YQ07w5_TT0Nli5uXBxSoWoOdt2X8/edit?usp=sharing> > provides the warning statements offered by MATLAB while running System -> > Update Diagram (and again, this is all I have because no error log file was > created). Do you have a suggestion on what could be causing this issue? > > > Thank you all again for your recent and productive help! > > > Best, > > Alec > > > > On Thu, Nov 10, 2016 at 5:12 PM, David MacMahon <dav...@berkeley.edu> > wrote: > > Hi, Alec, > > I suspect your MLIB_DEVEL_PATH environment variable is not getting set. > This error message... > > An error or warning occurred during a callback while saving > '/casper_library/casper_library_bus.slx'. > > > …shows that matlab is trying to save the casper_library_bus.slx file in > "/casper_library" (i.e. one level down from the root directory). I suspect > that’s not really where you’re mlib_devel lives. The matlab code that > writes this file is shown in this part of the error message... > > Error in casper_library_bus_init (line 285) > filename = save_system(mdl,[getenv('MLIB_DEVEL_PATH'), > '/casper_library/', 'casper_library_bus']); > > > As you can see, if "getenv('MLIB_DEVEL_PATH')" returns an empty string, > the the file name which will be used is > "/casper_library/casper_library_bus" (plus any extension that gets added by > matlab/simulink). This is the path that is being used (see previous error > message) so that indicates that MLIB_DEVEL_PATH is not being set in your > environment (or maybe set but not "exported"). I think this is supposed to > happen automatically as part of the "startsg" script. > > HTH, > Dave > > > > > <poco_wide_12_r316_sysgen_error.log> > > <bram_error.png> > > > > >
