Thanks for the help everyone. A combination of all the tricks listed in this thread and in others (such as putting a d7 in the System Generator Block) has allowed me to use these libraries. I am now at some issues with timing constraints, which I hope to solve next.
-Sam On Tue, Feb 1, 2011 at 12:00 PM, David MacMahon <dav...@astro.berkeley.edu> wrote: > 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 >>>>>> >>>>> >>>>> >>>> >>> >>> >> > >
