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