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