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