You're right that it would be better to change in both places. In fact it would be best it the library version of the block was completely empty. If you wanted to do this, and make any necessary changes to the init script (there might not be any), I'll gladly merge it into the main casper-astro repo.
Thanks Jack On Fri, 1 May 2015 4:10 am James Gowans <james.gow...@uct.ac.za> wrote: > Thanks Jack, that makes sense! > I still find it somewhat disconcerting that the mdl file contains a block > so different to what the init script generates, but I suppose it doesn't > really matter. > > I'm running a compile now but I don't foresee any problems. > I've made a pull request against ska-sa for your change. > > James > ------------------------------ > *From:* Jack Hickish [jackhick...@gmail.com] > *Sent:* Thursday, April 30, 2015 8:33 PM > *To:* James Gowans; G Jones > > *Cc:* casper@lists.berkeley.edu > *Subject:* Re: [casper] cross_multiplier block can't find cram_init > function > Hi James > > On Thu, 30 Apr 2015 at 01:21 James Gowans <james.gow...@uct.ac.za> wrote: > >> Hi Jack and Glen, >> >> Thanks very much - that commit does exactly what I needed. :-) >> >> Two follow-on questions: >> >> The change you made only modifies the init script, not the mdl files >> which contains that cross_multiplier block. Why didn't you rather replace >> the cram/uncram blocks (as well as do some of your other alterations) in >> the mdl file? This seems to me the logical place to make changes, but >> perhaps I misunderstand how green blocks work?... >> > > The init script needed changing either way, since it [attempts to] place > cram blocks, it doesn't just modify the parameters of blocks which are > already there. This has to be the case, because the block needs to > dynamically add/remove crams depending on the number of inputs. If it was > changed in the mdl file to the new bus block, the init script would break > the block when it attempted to redraw. > Having changed the init script, I guess I could have also changed the > block saved in the library too to remove the crams, but I generally try to > avoid modifying library mdl files wherever possible because it becomes a > bit of a version control nightmare. You'll notice that a lot of the newer > blocks in the library are saved as empty shells, for this reason. On > initialisation, the init script will overwrite the innards with the correct > stuff. > If, on the other hand, the init file doesn't work with the block in the > mdl file as saved, then that's a screwup on my part. > > > >> >> In my application I use the full resolution of the cross multiplier, so >> the cvrt blocks do nothing, but still consume logic. Would it be worth it >> do add some functionality to the init script to detect this case and remove >> the cvrt blocks, or is it uncommon to use the full resolution? >> >> > If their latency is zero, and the precision is full, the convert blocks > shouldn't use any hardware resources. You could add this to the init script > to save having superfluous blocks floating around, but I don't think this > should impact your compiles. > > Cheers, > Jack > > > >> Thanks again, >> James Gowans >> ------------------------------ >> *From:* Jack Hickish [jackhick...@gmail.com] >> *Sent:* Tuesday, April 28, 2015 10:27 PM >> *To:* G Jones; James Gowans >> *Cc:* casper@lists.berkeley.edu >> *Subject:* Re: [casper] cross_multiplier block can't find cram_init >> function >> >> Hi James, >> >> I think this commit -- >> https://github.com/jack-h/mlib_devel/commit/c34d3e539552b2f75a5e0452a72b0669b66a187b >> -- should solve your problem. >> >> Cheers, >> Jack >> >> On Tue, 28 Apr 2015 at 04:59 G Jones <glenn.calt...@gmail.com> wrote: >> >>> Cram was my old version of the new bus creation utilities. The bus >>> library in the CASPER block set supersedes the cram/uncram block, so the >>> cross multiplier block should be updated. For reference, the cram block is >>> in the old gavrt library. >>> >>> Glenn >>> On Apr 28, 2015 7:44 AM, "James Gowans" <james.gow...@uct.ac.za> wrote: >>> >>>> Hi, >>>> >>>> I'm on the latest commit of ska-sa/mlib-devel and am trying to use the >>>> CASPER DSP -> Correlator -> cross_multiplier green block. >>>> >>>> When I compile the design I get the following error: >>>> >>>> >>>> *Error in 'jgowans_fft_4chan/cross_multiplier/pack0_0': Initialization >>>> commands cannot be evaluated. Caused by: Undefined function 'cram_init' for >>>> input arguments of type 'char'.* >>>> >>>> Grepping through the repo I would agree that *cram_init* does not >>>> exist. Does anyone know where it's gone to or what can be done to get this >>>> block compiling? >>>> >>>> The mask parameters are: >>>> Input steams: 4 >>>> Aggregation: 2 >>>> In: 18_17 >>>> Out: 32_31 >>>> (others default) >>>> >>>> Regards, >>>> James Gowans >>>> M.Sc Student, University of Cape Town >>>> ------------------------------ >>>> UNIVERSITY OF CAPE TOWN >>>> >>>> This e-mail is subject to the UCT ICT policies and e-mail disclaimer >>>> published on our website at >>>> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable >>>> from +27 21 650 9111. This e-mail is intended only for the person(s) >>>> to whom it is addressed. If the e-mail has reached you in error, please >>>> notify the author. If you are not the intended recipient of the e-mail you >>>> may not use, disclose, copy, redirect or print the content. If this e-mail >>>> is not related to the business of UCT it is sent by the sender in the >>>> sender's individual capacity. >>>> >>>
