[casper] CASPER Workshop 2010: 2nd announcement

2010-05-10 Thread Jonathan Weintroub
Preparations are well underway for the 2010 CASPER  (Collaboration for  
Astronomy Signal Processing and Electronics Research) Workshop, to be  
held at the Harvard-Smithsonian Center for Astrophysics, Cambridge, MA  
from 16 to 20 August. We expect this to be an exciting and well  
attended event, with a slate of speakers and attendees from the CASPER  
community and from industry (Xilinx and nVidia).


Please register, and optionally submit a title and a short abstract  
for a 20 minute presentation here:

http://casper.berkeley.edu/workshop_2010/

Please note the abstract deadline is considerably earlier than the  
registration deadline.

Deadline for abstracts:  15 June 2010
Deadline for registration 31 July 2010 (or when filled)

Both new registrants, and those who have already registered, please  
help us out by submitting your proposed talk title and a short plain  
text abstract as soon as possible.  This is very helpful for the  
organizers to see how the workshop is shaping up and to balance the  
program. The abstracts are published when submitted, so that potential  
attendees can see what has already been submitted, and tune their  
contributions accordingly.   You can continue to edit your abstracts  
after submission.  (We had some early hiccups with the abstract  
submission form, so those who have already submitted please check and  
see if it's gone missing . . . sorry if you need to resubmit).


The registration fee is $150, reduced to $50 for students. This will  
cover refreshments and lunches over the five days There is a separate  
secure page linked from the above page for payment of the fee.   
Registration is thus a two step process.  Payment of the fee will  
confirm your registration.  Please note that there is a hard limit of  
100 attendees, and the workshop will be closed when we have that  
number confirmed.


A note on workshop structure:  we plan to have talks, hands on  
tutorials, as well as break out sessions and working groups. The first  
day, Monday 16 August, will be dedicated to basic hands on tutorials,  
with some talks on the took flow as appropriate.  Advanced CASPERites  
may choose to skip this day.   The remaining days will consist of  
intensive talks until just past lunch time, with the afternoon set  
aside for hands on, working groups, and informal interaction.


Travel and hotel information is on the CASPER wiki and linked from the  
registration page.


We are working on the possibility of need-based partial travel support  
for student participants, and this will be announced, and requests  
solicited, if and when confirmed.


CASPER 2010 Mission Statement
Attended by about 100 international astronomy digital signal  
processing (DSP) experts, the annual meeting of the global CASPER  
collaboration traditionally includes a review of the past year's  
accomplishments and hands-on training for old hands and new recruits  
alike.   Historically CASPER DSP hardware has been FPGA-based, and the  
2010 CfA workshop in particular aims to reach out to the wider DSP  
community so as to set a foundation for a broadened CASPER mission.   
The collaboration plans to explore opportunities in heterogeneous  
computing, exploiting natural synergies between FPGAs, and other  
platforms such as Graphics Processing Units (GPUs), fast multi-core  
CPUs, high bandwidth coherent data storage and quasi-real time post- 
processing.   The mission of CASPER is to streamline, simplify, and  
thereby accelerate the design of astronomy instrumentation by  
promoting design reuse through the development of platform- 
independent, open-source hardware and software.



Please feel free to forward this message to colleagues who may be  
interested.   We look forward to seeing you in Cambridge.


Jonathan Weintroub, Lincoln Greenhill, Jim Moran and the SOC




Re: [casper] config issue with window() function?

2010-05-10 Thread Mark Wagner
Hi Steve,

I'm not sure if you've done this already, but the first thing I would do
would be to replace the block with a new one from the library.  If this
doesn't work, I would run the mask script from the matlab command prompt,
which, if it doesn't fix the problem, will give you a more verbose error.

Mark

On Mon, May 10, 2010 at 2:34 PM, Steve Maher stephen.f.ma...@nasa.govwrote:

 Hi all,

 I am having an (basic configuration?) issue with *pfb_coeff_gen *and the *
 window()* function.

 I get the following error when compiling a pfb_coeff_gen block:

 Error in 'testHamming/pfb_coeff_gen/ROM1': Parameter 'pfb_coeff_gen_calc(6,
 4,'hamming',0, 0,1,1)' cannot be evaluated.  MATLAB error message: Undefined
 function or method 'window' for input arguments of type 'char'.


 I seem to have the Signal Processing Library installed correctly as the
 test *window('hamming', 1024)* passes at line 62 of pfb_coeff_gen_init.m.

 Tips appreciated.

 Steve



Re: [casper] basic question about yellow blocks

2010-05-10 Thread David MacMahon

Hi, Rick,

I know that the Xilinx synthesis tool (xst) recognizes the LOC and  
related constraints as VHDL attributes and propagates them to  
downstream tools.  I believe there is a Verilog analog.


Dave

On May 10, 2010, at 16:45 , Rick Raffanti wrote:


Hi Henry,
   Thanks, I get that.  But I've also found that the black box  
procedure that Jack Hickish pointed me to seems to work really  
nicely: I can put some Verilog in a black box, connect up signal  
sources and sinks, and simulate it without any Matlab m language  
fol-du-rol.  So now I have a small chunk of Verilog which does what  
I want, and I can simulate it, and its input side is clocked by a   
ZDOK pair, and its output side is clocked by the system clock  
(which the black box process connects up).  If I could only  
connect it to the %$#)~! pins I'd be done!


Rick


Henry Chen wrote:

Hi Rick,

That's actually a pretty good question. A not-so-good answer is that
you'd make a yellow block when existing yellow blocks don't provide
all of the functionality you need ;)

Basically, Simulink/SysGen is very poorly suited for things that are
not well abstracted by pipelined logic in a single clock domain. So
anything dealing with clock management, crossing different clock
domains, low-level I/O constraints, asynchronous delay paths, etc.
would likely need its own yellow block.

For a lot of basic interface needs, using the GPIO yellow block while
clocking the whole FPGA (including the I/O data) with usr_clk might
be sufficient.

Thanks,
Henry

On 5/10/2010 4:16 PM, Rick Raffanti wrote:

At the risk of looking like a knucklehead:

I'm working through the How to make a yellow block memo, and it  
seems complicated.  But it seems like the whole purpose, at least  
in my case where I have a digital input, not an ADC, is simply to  
define the pin assignments of my HDL.  So my question is Why to  
make a yellow block?.


Can anyone explain?

Many thanks.

Rick