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] Roach1 not working
Thank you John for replying, I saw this wiki page before. The Jtag suggested in this website is no longer available. I was wondering you can suggest me a cheaper Jtag that is compatible with the micro processor on the roach board. Thanks and regards, Nishanth On Thu, Apr 30, 2015 at 7:56 AM, John Ford wrote: > Hi. I think maybe you have "bricked" your ROACH, i.e. the bootloader is > messed up. You'll possibly need a jtag pod and software to reload it. > See: > > https://casper.berkeley.edu/wiki/ROACH_Debricking > > John > > > > Hi All, > > > > We bought a new desktop and I tried installing nfs boot on to the new > > computer to boot the roach1 and was trying to bring the roach1 up. But I > > think I messed up installing something somewhere and the roach 1 is not > > returning anything to the minicom terminal at all. > > > > I am sure it is connected to the right port because I can see it on the > > terminal using dmesg command. > > > > I tried using different client like cutecom and putty and it still does > > not > > work. I did a basic loop back test to minicom terminal all the characters > > are showing up properly. > > > > I switched back everything to the old computer where it used to work > > before > > and it does not work there too. I really dont know if the flash > bootloader > > is messed up. Is there a way to check if i have done something wrong or > > reset the whole machine. I did reset the whole machine using the reset > > switch in front of the roach. Before it stopped returning characters to > > the > > minicom terminal I was getting error messages like kernel panic etc. now > > even that is not showing up. > > > > Can someone help me in this regard. > > > > Warm regards, > > Nishanth Shivashankaran > > Arizona State University > > Email:nshiv...@asu.edu > > > > > -- Nishanth Shivashankaran Arizona State University Phone:-480-246-6866 Email:nshiv...@asu.edu
Re: [casper] Roach1 not working
Hi. I think maybe you have "bricked" your ROACH, i.e. the bootloader is messed up. You'll possibly need a jtag pod and software to reload it. See: https://casper.berkeley.edu/wiki/ROACH_Debricking John > Hi All, > > We bought a new desktop and I tried installing nfs boot on to the new > computer to boot the roach1 and was trying to bring the roach1 up. But I > think I messed up installing something somewhere and the roach 1 is not > returning anything to the minicom terminal at all. > > I am sure it is connected to the right port because I can see it on the > terminal using dmesg command. > > I tried using different client like cutecom and putty and it still does > not > work. I did a basic loop back test to minicom terminal all the characters > are showing up properly. > > I switched back everything to the old computer where it used to work > before > and it does not work there too. I really dont know if the flash bootloader > is messed up. Is there a way to check if i have done something wrong or > reset the whole machine. I did reset the whole machine using the reset > switch in front of the roach. Before it stopped returning characters to > the > minicom terminal I was getting error messages like kernel panic etc. now > even that is not showing up. > > Can someone help me in this regard. > > Warm regards, > Nishanth Shivashankaran > Arizona State University > Email:nshiv...@asu.edu >
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.
