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 [[email protected]] Sent: Thursday, April 30, 2015 8:33 PM To: James Gowans; G Jones Cc: [email protected] Subject: Re: [casper] cross_multiplier block can't find cram_init function Hi James On Thu, 30 Apr 2015 at 01:21 James Gowans <[email protected]<mailto:[email protected]>> 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 [[email protected]<mailto:[email protected]>] Sent: Tuesday, April 28, 2015 10:27 PM To: G Jones; James Gowans Cc: [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[email protected]>> 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<tel:%2B27%2021%20650%209111>. 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.
