[casper] two spare 1GHz iADCs?

[Jeffrey John McMahon]

Hi,

I am looking for two 1 GHz iADC boards.  I hear from Jack Hickish that there 
are potentially several stockpiles of unused iADC boards.  If you happen to 
have one of these stockpiles, would you be willing to lend, sell, or trade two 
to my group?

thanks -Jeff

Jeff McMahon
Associate Professor 
Dept. of Physics
University of Michigan
Ann Arbor, Mi 48109
jeff...@umich.edu
734 615 2553

Re: [casper] cross_multiplier block can't find cram_init function

[Jack Hickish]

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

Re: [casper] cross_multiplier block can't find cram_init function

[James Gowans]

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