Hi, Sam, I have some more details for you. Many of the casper_library blocks "remember" their mask parameters so that their initialization scripts can quickly determine whether any parameter has changed. If an initialization script sees that no parameter has changed, it will not run any further since it has already initialized the block with the given parameters. Without this optimization, large designs took a very, very long time to do "update diagram" or "generate" (since "update diagram" is the first part of "generate"). This works fine unless the initialization script itself has changed. In this case, you want to script to run, but it refuses to thinking that it's job has already been done. The solution (work around) for this is to change a mask parameter (e.g. increase add_latency by 1), click OK to let the new script run with the undesired/modified parameter value, then change the mask parameter back to the original value to get the script to run with the desired/original parameter value.
Another issue that can arise is if the structure of a block has changed in the library. Since the links to casper_library blocks are disabled in existing designs, they may not contain the same sub-blocks as the corresponding library block. Obviously, this can be problematic structurally, but it can also be problematic from an init script point of view since the "old" block with disabled link will be running the "new" init script passing it the "old" mask parameters. In short, if you update your mlib_devel, you will probably want to go through your design to delete and re-add the casper_library blocks one-by-one (making sure to preserve/adapt the mask dialog settings as necessary). Without doing this it is hard to tell whether you're actually getting the advantages of the latest library blocks. Hope this helps, Dave On Feb 1, 2011, at 5:30 AM, Samuel Tun wrote: > Oh, good. I guess I was reading too much into what Model Advisor was > telling me. Thanks for the clarification. > -Sam > > > On Tue, Feb 1, 2011 at 8:19 AM, Jason Manley <jasonman...@gmail.com> wrote: >> Disabled links are fine. This is normal. Blocks cannot be updated (redrawn >> when you change parameters) if they're locked to the library blocks. So we >> disable the links so that they can be redrawn for each user's requirements. >> The init scripts of each block do this automatically. >> >> The SID warnings appeared when we started playing with the later libraries. >> They are annoying but harmless. >> >> Jason >> >> >> On 01 Feb 2011, at 15:14, Samuel Tun wrote: >> >>> First, to answer David's question, the design is created with the >>> latest version of the CASPER libraries (mlib_devel) available in the >>> repository, 10.1. I am getting the error when loading the libraries >>> under the BWRC fork. >>> >>> The CASPER DSP block set is loading in the Simulink browser, and I can >>> drag and crop blocks into the mdl. Then I minimize and restore as you >>> suggested, but no change. Now, I believe that I may have gotten the >>> terms wrong, the links aren't broken, they are disabled. I'm not sure >>> if this makes a difference. It seems all the CASPER blocks are >>> disabled, even after I load them onto the mdl from the CASPER library >>> and reconnect. I notice that when the I start MATLAB with the BWRC >>> fork libraries loading I get a lot of warnings about various Xilinx >>> blocks not having a parameter named 'SID', something that does not >>> happen when I load the regular 10.1 libraries. >>> >>> Sorry if I am messing terms up, but I hope the description helps. >>> >>> Thanks, >>> Sam >>> >>> >>> On Mon, Jan 31, 2011 at 5:13 PM, Suraj Gowda <surajgo...@berkeley.edu> >>> wrote: >>>> Hi Sam, >>>> >>>> This might be a case where Simulink doesn't find the library. Are the >>>> libraries visible in the Simulink LIbrary browser? if they are, try pulling >>>> any block from the CASPER DSP blockset into your design, minimize the .mdl >>>> and then re-examine it. Are the links still broken after this? >>>> >>>> As far as I know, update design is not intended to fix this error. >>>> >>>> _Suraj >>>> >>>> On Jan 31, 2011, at 2:00 PM, Samuel Tun wrote: >>>> >>>>> Hello, >>>>> >>>>> I am wondering if anyone's encountered the same problem as me, where >>>>> using more advanced libraries than the ones in which a design was >>>>> created breaks all the links? We are working on a realtively simple >>>>> correlator design, which was created with and more or less works in >>>>> the CASPER 10.1 libraries. However, we would like to get things >>>>> working at a faster clock rate, which is apparently possible with the >>>>> more optimized schemes in the BWRC libraries. I had understoon that I >>>>> will have to replace some of the optmized blocks, such as the fft and >>>>> pfbs. However, when I open the design with the BWRC libraries loaded, >>>>> almost all the links in the design are broken, as reported by the >>>>> model advisor. I tried using the update design option but, after a >>>>> couple of hours of running, nothing happened. >>>>> >>>>> I've searched the archives and I did not find a straight answer to >>>>> this, so I hope I'm not asking for something that's already been >>>>> discussed. >>>>> >>>>> Thank you much, >>>>> Sam Tun >>>>> >>>> >>>> >>> >> >> >
