Re: [casper] cross_multiplier block can't find cram_init function
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 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 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 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" 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 >>>>
Re: [casper] cross_multiplier block can't find cram_init function
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 mailto: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<mailto:jackhick...@gmail.com>] Sent: Tuesday, April 28, 2015 10:27 PM To: G Jones; James Gowans Cc: casper@lists.berkeley.edu<mailto: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 mailto: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" mailto: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.
Re: [casper] cross_multiplier block can't find cram_init function
Hi James On Thu, 30 Apr 2015 at 01:21 James Gowans 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 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" 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. >>> >>
Re: [casper] cross_multiplier block can't find cram_init function
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?... 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? 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 mailto: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" mailto: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.
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 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" 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. >> >
Re: [casper] cross_multiplier block can't find cram_init function
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" 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. >
[casper] cross_multiplier block can't find cram_init function
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.
