[casper] kit surplus to requirement?

[Neil Salmon]

Dear All,

I'll be leaving Manchester Metropolitan university (MMU) at the end of December 
2020 to set up my own concern (mmw sensors). This will undertake small scale 
systems research into novel microwave and millimetre wave sensors (mainly 10 to 
100 GHz). As a start-up it is useful to have some building block technologies, 
things like: waveguide/coaxial transitions, waveguide sections, feed-horns, 
directional couplers, circulators/isolators, lenses, dishes, receivers, 
amplifiers, mixers, test gear etc.

The costs of new purchases of these items are too high for me to bear. However, 
many laboratories retain much of this kit in working order but unused for years 
in store rooms. If you have any such pieces you would like to donate (or know 
others who might be willing to part with such items), please drop me a line at 
salmon...@tiscali.co.uk<mailto:salmon...@tiscali.co.uk> (corrected from 
previous email). For suitable items I'd be happy to pay postage, or if in the 
UK collect.

Many thanks for any help.
Neil Salmon
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/56c45f49ccf640508954ed4e8b8d0e2c%40ASEX01.ad.mmu.ac.uk.

[casper] kit surplus to requirement?

[Neil Salmon]

Dear All,

I'll be leaving Manchester Metropolitan university (MMU) at the end of December 
2020 to set up my own concern (mmw sensors). This will undertake small scale 
systems research into novel microwave and millimetre wave sensors (mainly 10 to 
100 GHz). As a start-up it is useful to have some building block technologies, 
things like: waveguide/coaxial transitions, waveguide sections, feed-horns, 
directional couplers, circulators/isolators, lenses, dishes, receivers, 
amplifiers, mixers, test gear etc.

The costs of new purchases of these items are too high for me to bear. However, 
many laboratories retain much of this kit in working order but unused for years 
in store rooms. If you have any such pieces you would like to donate (or know 
others who might be willing to part with such items), please drop me a line at 
salmon...@tiscail.co.uk<mailto:salmon...@tiscail.co.uk>. For suitable items I'd 
be happy to pay postage, or if in the UK collect.

Many thanks for any help.
Neil Salmon
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/e049835aeae44fc1b3354812ae34aae7%40ASEX01.ad.mmu.ac.uk.

RE: [casper] references to recent cross-correlator technology developments

[Neil Salmon]

Hi Jack,

Again that’s for advice and the offer to run the benchmark. Let me learn more 
about GPU’s in the meantime and I’d hope to get back to you on this.

Best wishes,
Neil

From: Jack Hickish 
Sent: 16 August 2020 12:18
To: casper 
Cc: Danny Price 
Subject: Re: [casper] references to recent cross-correlator technology 
developments


On Sun, 16 Aug 2020, 11:59 am Neil Salmon, 
mailto:n.sal...@mmu.ac.uk>> wrote:
Hi Dan,

I really appreciate the good points you make.

Certainly, NLogN versus N^2 in processing power for the two approaches can make 
a big difference. Some of the active (radar) security screening portal systems 
currently use GPUs to the FT’s. It is challenging, as in the near-field region 
it’s a 3-D imaging problem. I’m trying to figure the most efficient algorithm 
to do this passively.

For security screening portals I’m looking at hundreds of channels, if not 
1000. I think that number should be sufficient, and beyond that I think the 
costs for the commercial security screening market will be too high. Certainly 
for a next demo system I’d be looking at several hundred channels. The forward 
simulation I have to generate the radiometric E-fields from scenes can at least 
trial possible creation algorithms. Some of the Chinese groups are building 
systems with 1000 channels.

However, with the GPUs I understood these to be good at high data rate, but 
only in a burst mode. If you had a sustained high data rate the specifications 
of the PCI express (something like 60 gbps) bus could not be realised over an 
extended period. On the basis of this I considered the GPUs not optimal for 
real-time processing? Is this still the case?
Hi Neil,

For "small" numbers of inputs, there's no reason not to be getting close to a 
sustained 90+ gbps of throughput for a bandwidth bound problem like correlation 
on a big GPU. This is certainly achievable in a radio astronomy setting where 
integration on the GPU is often long enough that the returning data rate is 
negligible.
I'd recommend pulling xGPU from GitHub and running a quick benchmark if you 
have a gpu to hand. Keeping in mind that the code hasn't been modified in a 
couple of years, I think you might be pleasantly surprised. If you don't have a 
gpu to hand I'd be happy to take a minute to run a benchmark for you on my 
(ever-growing) collection of cards if you give me the system parameters.

Concerning the computation of a floating point correlation, I gather some are 
using more efficient integer arithmetic for this, then perhaps storing the 
result in a floating point accumulator?

Depends on the codebase / user. The 8-bit integer optimized xgpu outputs 
accumulated data as 32 bit ints, similar to Casper's xengine FPGA module. Can't 
speak for the various other implementations folks use.

Cheers
Jack


Best wishes,
Neil

From: Dan Werthimer mailto:d...@ssl.berkeley.edu>>
Sent: 15 August 2020 18:31
To: CASPER Mailing List 
mailto:casper@lists.berkeley.edu>>
Cc: Danny Price mailto:dan...@berkeley.edu>>
Subject: Re: [casper] references to recent cross-correlator technology 
developments


Hi Neil,

regarding using GPU's or FPGA's for the X engine of an FX correlator:

You probably appreciate GPU's are best used in correlators with a large number 
of antennas.
The problem with using GPU's for a small number of antennas is the GPU is 
limited by input data rate.

The correlator input data rate is proportional to Nantenna, and the correlator 
X engine computation rate is proportional to Nantenna^2.
I think with modern GPUs you need about 1024 antennas before you aren't I/O 
bound and can take advantage of the GPU's computational power;
otherwise the GPU will be idle waiting for data.

One way out of this problem is to find an application which can use the GPU for 
additional tasks besides correlation - tasks that don't need much I/O.
Another possibility is to use cheap GPU's that can't do much computation, but 
then the host computer dominates the cost and power comsumption of the Xengine.

FPGA's have a lot more I/O capacity and are lower power than GPU's, but as you 
know, they are harder to program.

I think most modern GPU's can do integer arithmetic with a selectable number of 
bits, similar to FPGA's.
But because floating point is easier, and many correlator GPU applications are 
I/O bound,
most people send their data as small fixed point numbers into the GPU for 
correlation (eg: 4 bit real, 4 bit imag), but then compute the correlation in 
floating point.

 Best Wishes,

Dan


On Fri, Aug 14, 2020 at 9:37 PM Neil Salmon 
mailto:n.sal...@mmu.ac.uk>> wrote:
Hi Danny,

GPU’s may be starting to rival FPGA’s in processing power for correlators. 
However, are GPU’s restricted to long word correlation, say 32-bit floating 
point, whereas in FPGA I’m assuming the bit length is variable, so you may 
cho

RE: [casper] references to recent cross-correlator technology developments

[Neil Salmon]

Hi Jack,

Thanks for the great points you raise.

I did consider previously a ‘hack’ to get short integer arithmetic out of 
32-bit words, but the Tensor cores look very attractive now when they do this 
directly.

Certainly, I have to re-evaluate the GPUs, given the costs and the potential 
less difficult programming of, it needs serious consideration.

Many thanks,
Neil

From: Jack Hickish 
Sent: 15 August 2020 18:49
To: casper 
Cc: Danny Price 
Subject: Re: [casper] references to recent cross-correlator technology 
developments

I'll join the group of people who aren't Danny responding to your message :)

These days GPUs have much better non-floating point performance -- Nvidia's 
tensor cores will do INT8 / INT4 compute which are (I gather) good for machine 
learning. The Tesla T4 card specs specifically state low-precision performance 
numbers.
Even before this trend, operations like 8-bit, 4-element dot-product were 
around, and are used to great effect in the xGPU library. And even before that, 
the cunning and guile of users could do things like coerce 32-bit integer 
arithmetic to perform multiple 4 bit operations per cycle (see, for example, 
the CHIME correlator).

So while it is true that FPGAs still have an edge in performing arbitrary 
precision operations with high efficiency, GPUs are fighting in that space too.

Cheers
Jack

On Sat, 15 Aug 2020 at 05:37, Neil Salmon 
mailto:n.sal...@mmu.ac.uk>> wrote:
Hi Danny,

GPU’s may be starting to rival FPGA’s in processing power for correlators. 
However, are GPU’s restricted to long word correlation, say 32-bit floating 
point, whereas in FPGA I’m assuming the bit length is variable, so you may 
choose say 4-bit integer correlation – which would match to a 4-bit ADC.

If you can’t adapt the word length for GPU correlators, then the FPGA 
technology still has an edge, because as far as correlation is concerned, I’m 
not sure if going to word lengths longer than 4-bit is resourceful use of 
silicon real estate?

What is your view on that?

I did include a section on correlators in the document on security screening 
imaging  https://ieeexplore.ieee.org/document/9154708 and some of your selected 
publications in the references – thank you.

Cheers,
Neil

From: Danny Price mailto:dan...@berkeley.edu>>
Sent: 20 July 2020 14:44
To: Neil Salmon mailto:n.sal...@mmu.ac.uk>>; 
casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: RE: [casper] references to recent cross-correlator technology 
developments

Hi Neil,

The correlation is indeed done in real time using stream processing frameworks 
for most interferometer telescopes. Conversion from (very sparse) visibilities 
to images is generally done offline (this can be very time consuming!).

There are a few real-time imaging systems: the EPIC correlator that Jack 
mentioned, and the realfast system on the VLA 
(https://science.nrao.edu/facilities/vla/observing/realfast) are good examples.

Cheers,
Danny

On 20 July 2020 at 9:55:06 pm, Neil Salmon 
(n.sal...@mmu.ac.uk<mailto:n.sal...@mmu.ac.uk>) wrote:
Hi Danny,

Thank you for these references.

For security screening systems the name of the game is real-time, ie an image 
in less than 1 second. However, I see a great many references to GPU based 
correlators. I was used to seeing these devices as off-line correlators, as in 
software correlators. Are the GPUs being used by the radio astronomy community 
as real-time correlators, or as software correlators?

Many thanks,
Neil

From: Danny Price mailto:dan...@berkeley.edu>>
Sent: 20 July 2020 12:21
To: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: Re: [casper] references to recent cross-correlator technology 
developments

Hi Neil,

To add to Jack's post, allow me to plug some overview articles that may be of 
interest. The first, https://arxiv.org/abs/1702.00442, was for an introduction 
for a special issue of JAI on DSP in radio astronomy in 2016. Table 1 
summarises some of the larger correlators: the references therein may be of 
use. Jack (et al)'s CASPER article in said JAI special issue is also a font of 
references: https://arxiv.org/abs/1611.01826. The full special issue article 
listing is up here: https://www.worldscientific.com/toc/jai/05/04.

More recently, here's my book chapter on real-time stream processing in radio 
astronomy, https://arxiv.org/abs/1912.09041, which delves a bit deeper into 
technical details for common approaches.

In terms of cutting edge, there are various groups working with the Xilinx 
RFSoC components for next-gen systems -- you will no doubt have seen some 
traffic on this list. The ASKAP telescope group have plans to use an Alveo 
Xilinx U280 accelerator card for high time resolution imaging + dedispersion, 
which is an alternative to the GPU correlator.

GPU correlators are still the most widespread for O(100) antennas. There's some 
discussio

RE: [casper] references to recent cross-correlator technology developments

[Neil Salmon]

Hi Dan,

I really appreciate the good points you make.

Certainly, NLogN versus N^2 in processing power for the two approaches can make 
a big difference. Some of the active (radar) security screening portal systems 
currently use GPUs to the FT’s. It is challenging, as in the near-field region 
it’s a 3-D imaging problem. I’m trying to figure the most efficient algorithm 
to do this passively.

For security screening portals I’m looking at hundreds of channels, if not 
1000. I think that number should be sufficient, and beyond that I think the 
costs for the commercial security screening market will be too high. Certainly 
for a next demo system I’d be looking at several hundred channels. The forward 
simulation I have to generate the radiometric E-fields from scenes can at least 
trial possible creation algorithms. Some of the Chinese groups are building 
systems with 1000 channels.

However, with the GPUs I understood these to be good at high data rate, but 
only in a burst mode. If you had a sustained high data rate the specifications 
of the PCI express (something like 60 gbps) bus could not be realised over an 
extended period. On the basis of this I considered the GPUs not optimal for 
real-time processing? Is this still the case?

Concerning the computation of a floating point correlation, I gather some are 
using more efficient integer arithmetic for this, then perhaps storing the 
result in a floating point accumulator?

Best wishes,
Neil

From: Dan Werthimer 
Sent: 15 August 2020 18:31
To: CASPER Mailing List 
Cc: Danny Price 
Subject: Re: [casper] references to recent cross-correlator technology 
developments


Hi Neil,

regarding using GPU's or FPGA's for the X engine of an FX correlator:

You probably appreciate GPU's are best used in correlators with a large number 
of antennas.
The problem with using GPU's for a small number of antennas is the GPU is 
limited by input data rate.

The correlator input data rate is proportional to Nantenna, and the correlator 
X engine computation rate is proportional to Nantenna^2.
I think with modern GPUs you need about 1024 antennas before you aren't I/O 
bound and can take advantage of the GPU's computational power;
otherwise the GPU will be idle waiting for data.

One way out of this problem is to find an application which can use the GPU for 
additional tasks besides correlation - tasks that don't need much I/O.
Another possibility is to use cheap GPU's that can't do much computation, but 
then the host computer dominates the cost and power comsumption of the Xengine.

FPGA's have a lot more I/O capacity and are lower power than GPU's, but as you 
know, they are harder to program.

I think most modern GPU's can do integer arithmetic with a selectable number of 
bits, similar to FPGA's.
But because floating point is easier, and many correlator GPU applications are 
I/O bound,
most people send their data as small fixed point numbers into the GPU for 
correlation (eg: 4 bit real, 4 bit imag), but then compute the correlation in 
floating point.

 Best Wishes,

Dan


On Fri, Aug 14, 2020 at 9:37 PM Neil Salmon 
mailto:n.sal...@mmu.ac.uk>> wrote:
Hi Danny,

GPU’s may be starting to rival FPGA’s in processing power for correlators. 
However, are GPU’s restricted to long word correlation, say 32-bit floating 
point, whereas in FPGA I’m assuming the bit length is variable, so you may 
choose say 4-bit integer correlation – which would match to a 4-bit ADC.

If you can’t adapt the word length for GPU correlators, then the FPGA 
technology still has an edge, because as far as correlation is concerned, I’m 
not sure if going to word lengths longer than 4-bit is resourceful use of 
silicon real estate?

What is your view on that?

I did include a section on correlators in the document on security screening 
imaging  https://ieeexplore.ieee.org/document/9154708 and some of your selected 
publications in the references – thank you.

Cheers,
Neil

From: Danny Price mailto:dan...@berkeley.edu>>
Sent: 20 July 2020 14:44
To: Neil Salmon mailto:n.sal...@mmu.ac.uk>>; 
casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: RE: [casper] references to recent cross-correlator technology 
developments

Hi Neil,

The correlation is indeed done in real time using stream processing frameworks 
for most interferometer telescopes. Conversion from (very sparse) visibilities 
to images is generally done offline (this can be very time consuming!).

There are a few real-time imaging systems: the EPIC correlator that Jack 
mentioned, and the realfast system on the VLA 
(https://science.nrao.edu/facilities/vla/observing/realfast) are good examples.

Cheers,
Danny

On 20 July 2020 at 9:55:06 pm, Neil Salmon 
(n.sal...@mmu.ac.uk<mailto:n.sal...@mmu.ac.uk>) wrote:
Hi Danny,

Thank you for these references.

For security screening systems the name of the game is real-time, ie an im

RE: [casper] references to recent cross-correlator technology developments

[Neil Salmon]

Hi Hari,

Many thanks for your good points here and the links to the papers.

Using FFT, directly instead of going around the correlation route, visibility 
function+FFT certainly minimises the computation when the density of antennas 
becomes higher than that of a minimally redundant array. When the array is 
fully filled then clearly an FFT is the way to go. The FFT approach is then 
more like radar processing of received signals where the norm is an almost 
fully filled array of antennas, to get around the aliasing problem, which is 
more severe for radar systems. I have considered this approach for far-field 
(range > 2d^2/lambda) imaging, the benefits being greater sensitivity and 
particularly faster responses, which would be key for commercial applications.

However, for portal security screening this is not just near-field, but extreme 
near field, right up almost to the inductive region of the antenna. In the 
extreme near field region, Fourier transform relationship between the image and 
the aperture sampled electric fields space breaks down, so the problem gets 
more complication. This is not just a problem for the FFT route, but also for 
the correlation approach. Using correlations from near-field array does 
actually work, but you have to create a 3-Dvisibility function, and then the 
Fourier transform relationship between the 3-D visibility function visibility 
and the 3-D image breaks down all except for a small volume around the phase 
centre of the 3-D image. A solution is to split the image up into a mosaic of 
physical smaller 3-D images.

The mosaic approach is more of a brute force approach but I’m sure there are 
more subtle and computationally efficient means to do the near-field imaging, 
when I get time I make some effort in this direction.

Best wishes,
Neil

From: Hariharan Krishnan 
Sent: 15 August 2020 15:51
To: casper@lists.berkeley.edu
Cc: Neil Salmon ; dan...@berkeley.edu
Subject: Re: [casper] references to recent cross-correlator technology 
developments

Hi Neil,
We have a GPU-based direct imaging correlator (EPIC - E-Field Parallel 
Imaging Correlator) implemented and tested on one of the LWA stations at 
Sevilleta. In EPIC we directly grid the fourier transformed voltages from the 
individual antennas and form real-time dirty maps without having to estimate 
the visibilities. EPIC can essentially produce images at high time resolution 
on the order of a few ms. Currently we are optimizing the GPU-part of EPIC to 
increase the operating bandwidth per node for a commensal transient imaging 
backend at LWA-SV.

You can refer to the following publications for more details on EPIC

https://academic.oup.com/mnras/article-abstract/486/4/5052/5484888

https://academic.oup.com/mnras/article/467/1/715/2917985

Regards,

Hari


On Mon, Jul 20, 2020 at 7:12 AM Neil Salmon 
mailto:n.sal...@mmu.ac.uk>> wrote:
Hi Danny,

Yes I can appreciate the difference here with respect to integration times. 
Furthermore, as our arrays tend to be more fully filled, some form of FT 
beam-former might be more efficient than a correlator. However, things do get 
more complicated in the near-field security screening scenarios where the FT 
relationship between physical space and spatial frequency space breaks down.

Cheers,
Neil

From: Danny Price mailto:dan...@berkeley.edu>>
Sent: 20 July 2020 14:44
To: Neil Salmon mailto:n.sal...@mmu.ac.uk>>; 
casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: RE: [casper] references to recent cross-correlator technology 
developments

Hi Neil,

The correlation is indeed done in real time using stream processing frameworks 
for most interferometer telescopes. Conversion from (very sparse) visibilities 
to images is generally done offline (this can be very time consuming!).

There are a few real-time imaging systems: the EPIC correlator that Jack 
mentioned, and the realfast system on the VLA 
(https://science.nrao.edu/facilities/vla/observing/realfast) are good examples.

Cheers,
Danny

On 20 July 2020 at 9:55:06 pm, Neil Salmon 
(n.sal...@mmu.ac.uk<mailto:n.sal...@mmu.ac.uk>) wrote:
Hi Danny,

Thank you for these references.

For security screening systems the name of the game is real-time, ie an image 
in less than 1 second. However, I see a great many references to GPU based 
correlators. I was used to seeing these devices as off-line correlators, as in 
software correlators. Are the GPUs being used by the radio astronomy community 
as real-time correlators, or as software correlators?

Many thanks,
Neil

From: Danny Price mailto:dan...@berkeley.edu>>
Sent: 20 July 2020 12:21
To: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: Re: [casper] references to recent cross-correlator technology 
developments

Hi Neil,

To add to Jack's post, allow me to plug some overview articles that may be of 
interest. The first, https://arxiv.org/abs/1702.00442, was for an introd

RE: [casper] references to recent cross-correlator technology developments

[Neil Salmon]

Hi Danny,

GPU’s may be starting to rival FPGA’s in processing power for correlators. 
However, are GPU’s restricted to long word correlation, say 32-bit floating 
point, whereas in FPGA I’m assuming the bit length is variable, so you may 
choose say 4-bit integer correlation – which would match to a 4-bit ADC.

If you can’t adapt the word length for GPU correlators, then the FPGA 
technology still has an edge, because as far as correlation is concerned, I’m 
not sure if going to word lengths longer than 4-bit is resourceful use of 
silicon real estate?

What is your view on that?

I did include a section on correlators in the document on security screening 
imaging  https://ieeexplore.ieee.org/document/9154708 and some of your selected 
publications in the references – thank you.

Cheers,
Neil

From: Danny Price 
Sent: 20 July 2020 14:44
To: Neil Salmon ; casper@lists.berkeley.edu
Subject: RE: [casper] references to recent cross-correlator technology 
developments

Hi Neil,

The correlation is indeed done in real time using stream processing frameworks 
for most interferometer telescopes. Conversion from (very sparse) visibilities 
to images is generally done offline (this can be very time consuming!).

There are a few real-time imaging systems: the EPIC correlator that Jack 
mentioned, and the realfast system on the VLA 
(https://science.nrao.edu/facilities/vla/observing/realfast) are good examples.

Cheers,
Danny

On 20 July 2020 at 9:55:06 pm, Neil Salmon 
(n.sal...@mmu.ac.uk<mailto:n.sal...@mmu.ac.uk>) wrote:
Hi Danny,

Thank you for these references.

For security screening systems the name of the game is real-time, ie an image 
in less than 1 second. However, I see a great many references to GPU based 
correlators. I was used to seeing these devices as off-line correlators, as in 
software correlators. Are the GPUs being used by the radio astronomy community 
as real-time correlators, or as software correlators?

Many thanks,
Neil

From: Danny Price mailto:dan...@berkeley.edu>>
Sent: 20 July 2020 12:21
To: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: Re: [casper] references to recent cross-correlator technology 
developments

Hi Neil,

To add to Jack's post, allow me to plug some overview articles that may be of 
interest. The first, https://arxiv.org/abs/1702.00442, was for an introduction 
for a special issue of JAI on DSP in radio astronomy in 2016. Table 1 
summarises some of the larger correlators: the references therein may be of 
use. Jack (et al)'s CASPER article in said JAI special issue is also a font of 
references: https://arxiv.org/abs/1611.01826. The full special issue article 
listing is up here: https://www.worldscientific.com/toc/jai/05/04.

More recently, here's my book chapter on real-time stream processing in radio 
astronomy, https://arxiv.org/abs/1912.09041, which delves a bit deeper into 
technical details for common approaches.

In terms of cutting edge, there are various groups working with the Xilinx 
RFSoC components for next-gen systems -- you will no doubt have seen some 
traffic on this list. The ASKAP telescope group have plans to use an Alveo 
Xilinx U280 accelerator card for high time resolution imaging + dedispersion, 
which is an alternative to the GPU correlator.

GPU correlators are still the most widespread for O(100) antennas. There's some 
discussion on GPU correlator performance in J. Kocz et al 2014 
(https://arxiv.org/abs/1401.8288); for O(100) inputs a GPU correlator will 
likely be memory bandwidth bound.

Cheers,
Danny

On 18 July 2020 at 7:54:49 pm, Neil Salmon 
(n.sal...@mmu.ac.uk<mailto:n.sal...@mmu.ac.uk>) wrote:
I need references on recent developments in cross-correlator technology for an 
IEEE paper on the subject of aperture synthesis imaging in the area of security 
screening of people for concealed weapons. Typical requirements for this 
application are cross-correlators that can process in real-time signals from 
hundreds of receiver channels with around 1 GHz of RF bandwidth. As none of 
this technology is commercially available off-the-shelf I’m dependent on the 
radio astronomy community to get the latest information of correlator 
development. This might be just technical knowhow on the building of 
correlators, or communities who would be willing to supply for a fee 
correlators to a security screening technology development company.

Could anyone provide me with any references of papers on recent correlator 
development that I could include in this paper?

Many thanks,
Neil
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "
--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group

RE: [casper] references to recent cross-correlator technology developments

[Neil Salmon]

I can imagine it's on the large size, but it’s the thought that counts 😊.

-Original Message-
From: Mark Halpern 
Sent: 20 July 2020 18:58
To: casper@lists.berkeley.edu
Subject: Re: [casper] references to recent cross-correlator technology 
developments

CHIME runs 2048 feeds into an FX correlator with 1/2 GHz bandwidth.

We form beams in real time and interrogate them at better than ms cadence for 
transients (frb).

The system is a bit big to picture hiding it in an airport.

mark


On 2020-07-20 07:12, Neil Salmon wrote:
> Hi Danny,
>
> Yes I can appreciate the difference here with respect to integration
> times. Furthermore, as our arrays tend to be more fully filled, some
> form of FT beam-former might be more efficient than a correlator.
> However, things do get more complicated in the near-field security
> screening scenarios where the FT relationship between physical space
> and spatial frequency space breaks down.
>
> Cheers,
>
> Neil
>
> *From:*Danny Price 
> *Sent:* 20 July 2020 14:44
> *To:* Neil Salmon ; casper@lists.berkeley.edu
> *Subject:* RE: [casper] references to recent cross-correlator
> technology developments
>
> Hi Neil,
>
> The correlation is indeed done in real time using stream processing
> frameworks for most interferometer telescopes. Conversion from (very
> sparse) visibilities to images is generally done offline (this can be
> very time consuming!).
>
> There are a few real-time imaging systems: the EPIC correlator that
> Jack mentioned, and the realfast system on the VLA
> (https://science.nrao.edu/facilities/vla/observing/realfast) are good
> examples.
>
> Cheers,
>
> Danny
>
> On 20 July 2020 at 9:55:06 pm, Neil Salmon (n.sal...@mmu.ac.uk
> <mailto:n.sal...@mmu.ac.uk>) wrote:
>
> Hi Danny,
>
> Thank you for these references.
>
> For security screening systems the name of the game is real-time, ie
> an image in less than 1 second. However, I see a great many
> references to GPU based correlators. I was used to seeing these
> devices as off-line correlators, as in software correlators. Are the
> GPUs being used by the radio astronomy community as real-time
> correlators, or as software correlators?
>
> Many thanks,
>
> Neil
>
> *From:*Danny Price mailto:dan...@berkeley.edu>>
> *Sent:* 20 July 2020 12:21
> *To:* casper@lists.berkeley.edu <mailto:casper@lists.berkeley.edu>
> *Subject:* Re: [casper] references to recent cross-correlator
> technology developments
>
> Hi Neil,
>
> To add to Jack's post, allow me to plug some overview articles that
> may be of interest. The first, https://arxiv.org/abs/1702.00442, was
> for an introduction for a special issue of JAI on DSP in radio
> astronomy in 2016. Table 1 summarises some of the larger
> correlators: the references therein may be of use. Jack (et al)'s
> CASPER article in said JAI special issue is also a font of
> references: https://arxiv.org/abs/1611.01826. The full special issue
> article listing is up here:
> https://www.worldscientific.com/toc/jai/05/04.
>
> More recently, here's my book chapter on real-time stream processing
> in radio astronomy, https://arxiv.org/abs/1912.09041, which delves a
> bit deeper into technical details for common approaches.
>
> In terms of cutting edge, there are various groups working with the
> Xilinx RFSoC components for next-gen systems -- you will no doubt
> have seen some traffic on this list. The ASKAP telescope group have
> plans to use an Alveo Xilinx U280 accelerator card for high time
> resolution imaging + dedispersion, which is an alternative to the
> GPU correlator.
>
> GPU correlators are still the most widespread for O(100) antennas.
> There's some discussion on GPU correlator performance in J. Kocz et
> al 2014 (https://arxiv.org/abs/1401.8288); for O(100) inputs a GPU
> correlator will likely be memory bandwidth bound.
>
> Cheers,
>
> Danny
>
> On 18 July 2020 at 7:54:49 pm, Neil Salmon (n.sal...@mmu.ac.uk
> <mailto:n.sal...@mmu.ac.uk>) wrote:
>
> I need references on recent developments in cross-correlator
> technology for an IEEE paper on the subject of aperture
> synthesis imaging in the area of security screening of people
> for concealed weapons. Typical requirements for this application
> are cross-correlators that can process in real-time signals from
> hundreds of receiver channels with around 1 GHz of RF bandwidth.
> As none of this technology is commercially available
>   

RE: [casper] references to recent cross-correlator technology developments

[Neil Salmon]

Hi Danny,

Yes I can appreciate the difference here with respect to integration times. 
Furthermore, as our arrays tend to be more fully filled, some form of FT 
beam-former might be more efficient than a correlator. However, things do get 
more complicated in the near-field security screening scenarios where the FT 
relationship between physical space and spatial frequency space breaks down.

Cheers,
Neil

From: Danny Price 
Sent: 20 July 2020 14:44
To: Neil Salmon ; casper@lists.berkeley.edu
Subject: RE: [casper] references to recent cross-correlator technology 
developments

Hi Neil,

The correlation is indeed done in real time using stream processing frameworks 
for most interferometer telescopes. Conversion from (very sparse) visibilities 
to images is generally done offline (this can be very time consuming!).

There are a few real-time imaging systems: the EPIC correlator that Jack 
mentioned, and the realfast system on the VLA 
(https://science.nrao.edu/facilities/vla/observing/realfast) are good examples.

Cheers,
Danny

On 20 July 2020 at 9:55:06 pm, Neil Salmon 
(n.sal...@mmu.ac.uk<mailto:n.sal...@mmu.ac.uk>) wrote:
Hi Danny,

Thank you for these references.

For security screening systems the name of the game is real-time, ie an image 
in less than 1 second. However, I see a great many references to GPU based 
correlators. I was used to seeing these devices as off-line correlators, as in 
software correlators. Are the GPUs being used by the radio astronomy community 
as real-time correlators, or as software correlators?

Many thanks,
Neil

From: Danny Price mailto:dan...@berkeley.edu>>
Sent: 20 July 2020 12:21
To: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: Re: [casper] references to recent cross-correlator technology 
developments

Hi Neil,

To add to Jack's post, allow me to plug some overview articles that may be of 
interest. The first, https://arxiv.org/abs/1702.00442, was for an introduction 
for a special issue of JAI on DSP in radio astronomy in 2016. Table 1 
summarises some of the larger correlators: the references therein may be of 
use. Jack (et al)'s CASPER article in said JAI special issue is also a font of 
references: https://arxiv.org/abs/1611.01826. The full special issue article 
listing is up here: https://www.worldscientific.com/toc/jai/05/04.

More recently, here's my book chapter on real-time stream processing in radio 
astronomy, https://arxiv.org/abs/1912.09041, which delves a bit deeper into 
technical details for common approaches.

In terms of cutting edge, there are various groups working with the Xilinx 
RFSoC components for next-gen systems -- you will no doubt have seen some 
traffic on this list. The ASKAP telescope group have plans to use an Alveo 
Xilinx U280 accelerator card for high time resolution imaging + dedispersion, 
which is an alternative to the GPU correlator.

GPU correlators are still the most widespread for O(100) antennas. There's some 
discussion on GPU correlator performance in J. Kocz et al 2014 
(https://arxiv.org/abs/1401.8288); for O(100) inputs a GPU correlator will 
likely be memory bandwidth bound.

Cheers,
Danny

On 18 July 2020 at 7:54:49 pm, Neil Salmon 
(n.sal...@mmu.ac.uk<mailto:n.sal...@mmu.ac.uk>) wrote:
I need references on recent developments in cross-correlator technology for an 
IEEE paper on the subject of aperture synthesis imaging in the area of security 
screening of people for concealed weapons. Typical requirements for this 
application are cross-correlators that can process in real-time signals from 
hundreds of receiver channels with around 1 GHz of RF bandwidth. As none of 
this technology is commercially available off-the-shelf I’m dependent on the 
radio astronomy community to get the latest information of correlator 
development. This might be just technical knowhow on the building of 
correlators, or communities who would be willing to supply for a fee 
correlators to a security screening technology development company.

Could anyone provide me with any references of papers on recent correlator 
development that I could include in this paper?

Many thanks,
Neil
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "
--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7aff8f2f6ed3482a8283e2994bbd9fc6%40ASEX03.ad.mmu.ac.uk<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7aff8f2f6ed3482a8283e2994bbd

RE: [casper] references to recent cross-correlator technology developments

[Neil Salmon]

Hi Danny,

Thank you for these references.

For security screening systems the name of the game is real-time, ie an image 
in less than 1 second. However, I see a great many references to GPU based 
correlators. I was used to seeing these devices as off-line correlators, as in 
software correlators. Are the GPUs being used by the radio astronomy community 
as real-time correlators, or as software correlators?

Many thanks,
Neil

From: Danny Price 
Sent: 20 July 2020 12:21
To: casper@lists.berkeley.edu
Subject: Re: [casper] references to recent cross-correlator technology 
developments

Hi Neil,

To add to Jack's post, allow me to plug some overview articles that may be of 
interest. The first, https://arxiv.org/abs/1702.00442, was for an introduction 
for a special issue of JAI on DSP in radio astronomy in 2016. Table 1 
summarises some of the larger correlators: the references therein may be of 
use. Jack (et al)'s CASPER article in said JAI special issue is also a font of 
references: https://arxiv.org/abs/1611.01826. The full special issue article 
listing is up here: https://www.worldscientific.com/toc/jai/05/04.

More recently, here's my book chapter on real-time stream processing in radio 
astronomy, https://arxiv.org/abs/1912.09041, which delves a bit deeper into 
technical details for common approaches.

In terms of cutting edge, there are various groups working with the Xilinx 
RFSoC components for next-gen systems -- you will no doubt have seen some 
traffic on this list. The ASKAP telescope group have plans to use an Alveo 
Xilinx U280 accelerator card for high time resolution imaging + dedispersion, 
which is an alternative to the GPU correlator.

GPU correlators are still the most widespread for O(100) antennas. There's some 
discussion on GPU correlator performance in J. Kocz et al 2014 
(https://arxiv.org/abs/1401.8288); for O(100) inputs a GPU correlator will 
likely be memory bandwidth bound.

Cheers,
Danny

On 18 July 2020 at 7:54:49 pm, Neil Salmon 
(n.sal...@mmu.ac.uk<mailto:n.sal...@mmu.ac.uk>) wrote:
I need references on recent developments in cross-correlator technology for an 
IEEE paper on the subject of aperture synthesis imaging in the area of security 
screening of people for concealed weapons. Typical requirements for this 
application are cross-correlators that can process in real-time signals from 
hundreds of receiver channels with around 1 GHz of RF bandwidth. As none of 
this technology is commercially available off-the-shelf I’m dependent on the 
radio astronomy community to get the latest information of correlator 
development. This might be just technical knowhow on the building of 
correlators, or communities who would be willing to supply for a fee 
correlators to a security screening technology development company.

Could anyone provide me with any references of papers on recent correlator 
development that I could include in this paper?

Many thanks,
Neil
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "
--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7aff8f2f6ed3482a8283e2994bbd9fc6%40ASEX03.ad.mmu.ac.uk<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7aff8f2f6ed3482a8283e2994bbd9fc6%40ASEX03.ad.mmu.ac.uk?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAAtMgq%3D_nce72fbSUWBZ62EiCxW5ojUgy%2ByAbPXHMNRd%3DXbLDw%40mail.gmail.com<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAAtMgq%3D_nce72fbSUWBZ62EiCxW5ojUgy%2ByAbPXHMNRd%3DXbLDw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/46372fbec8c34c909df5b72793ec1d09%40ASEX01.ad.mmu.ac.uk.

[casper] references to recent cross-correlator technology developments

[Neil Salmon]

I need references on recent developments in cross-correlator technology for an 
IEEE paper on the subject of aperture synthesis imaging in the area of security 
screening of people for concealed weapons. Typical requirements for this 
application are cross-correlators that can process in real-time signals from 
hundreds of receiver channels with around 1 GHz of RF bandwidth. As none of 
this technology is commercially available off-the-shelf I'm dependent on the 
radio astronomy community to get the latest information of correlator 
development. This might be just technical knowhow on the building of 
correlators, or communities who would be willing to supply for a fee 
correlators to a security screening technology development company.

Could anyone provide me with any references of papers on recent correlator 
development that I could include in this paper?

Many thanks,
Neil
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7aff8f2f6ed3482a8283e2994bbd9fc6%40ASEX03.ad.mmu.ac.uk.

[casper] radio astronomy receivers/digital correlators for quantum entanglement research

[Neil Salmon]

Dear All,

Historically, experiments in quantum entanglement have been performed in the 
optical band and near IR/UV, unless you cool to cryogenic temperatures 
(milliKelvin), so the thermally generated photons don't swamp the entangled 
photon pairs.

However, receiver concepts exploiting radio astronomy receivers and digital 
correlators may be exploited to conduct entanglement experiments in the 
microwave or millimetre wave band at ambient temperature. The system concepts 
are discussed at:

https://doi.org/10.1016/j.jmmm.2020.166435

This may enable a new outlet for radio astronomy receiver technology.

Happy to exchange ideas on the subject.

many thanks,
Neil

https://www.mmw-sensors.org

"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/dad4f03f9b0a4e4c90bb2ad53814c385%40ASEX01.ad.mmu.ac.uk.

[casper] RE: Matlab Toolbox Requirements

[Neil Salmon]

I’m not sure about the CASPER plan, but there’s a whole load of free modules 
from a multitude of users from many other areas, including tensorflow, it must 
be the way forward now. When I write new code I go straight to Python and bring 
in C++ for speed. Good luck, N.

From: 'Christman, Nicholas P' via casper@lists.berkeley.edu 

Sent: 08 January 2020 18:01
To: casper@lists.berkeley.edu
Subject: [casper] RE: Matlab Toolbox Requirements

Thank you Neil for the quick response. I agree and think that is an excellent 
path for the future… is a “full Python” toolflow in a working state? If I’m not 
mistaken, migrating to Python is the future plan for the CASPER toolflow but it 
is not yet developed nor is it being used yet. Or am I wrong?

Thanks,

R/
Nick
__
Nicholas Christman
Electrical Engineer,
Systems Engineering / Testing & Evaluation,
Advanced Engineered Systems Group
Pacific Northwest National Laboratory

From: Neil Salmon mailto:n.sal...@mmu.ac.uk>>
Sent: Wednesday, January 08, 2020 9:51 AM
To: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: [casper] RE: Matlab Toolbox Requirements

In the longer term, move over to Python. N

From: 'Christman, Nicholas P' via 
casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu> 
mailto:casper@lists.berkeley.edu>>
Sent: 08 January 2020 17:38
To: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: [casper] Matlab Toolbox Requirements

Good Morning CASPER Group,

My name is Nick Christman and I’m currently working through the SKARAB / CASPER 
toolflow integration process. Under normal circumstances, my organization has 
access to most of the Matlab toolboxes; however, it seems our project will need 
the DSP Toolbox license (not included by our org) which essentially means we 
will need to acquire standalone Matlab + Simulink licenses and all of the other 
toolboxes necessary to work with the SKARAB hardware. Herein lies our dilemma 
and the reason I’m reaching out to the group.

Ideally, to remain efficient and economical for the project, we would acquire 
only the necessary Matlab toolboxes that will allow us to execute the CASPER 
toolflow. Has anyone attempted this type of “minimal” installation for the 
CASPER toolflow? If so, do you have a list of required toolboxes? Or perhaps 
there is an alternative approach to solve our dilemma?

Thank you and I appreciate your support,

R/
Nick
__
Nicholas Christman
Electrical Engineer,
Systems Engineering / Testing & Evaluation,
Advanced Engineered Systems Group
Pacific Northwest National Laboratory

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/SA9PR09MB503902B9F5F69F372432ABB3F03E0%40SA9PR09MB5039.namprd09.prod.outlook.com<https://protect2.fireeye.com/v1/url?k=f0d6f41d-ac63cad2-f0d6de08-0cc47adc5e60-6a9c244e43d78af5&q=1&e=882f3faa-35e2-4bc3-86c4-e32428668490&u=https%3A%2F%2Fgroups.google.com%2Fa%2Flists.berkeley.edu%2Fd%2Fmsgid%2Fcasper%2FSA9PR09MB503902B9F5F69F372432ABB3F03E0%2540SA9PR09MB5039.namprd09.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter>.
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "
--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7b6ca0f6616b4aa0b48554a21af5cbbb%40ASEX01.ad.mmu.ac.uk<https://protect2.fireeye.com/v1/url?k=bf8c77a5-e339496a-bf8c5db0-0cc47adc5e60-68abc148b33213ea&q=1&e=882f3faa-35e2-4bc3-86c4-e32428668490&u=https%3A%2F%2Fgroups.google.com%2Fa%2Flists.berkeley.edu%2Fd%2Fmsgid%2Fcasper%2F7b6ca0f6616b4aa0b48554a21af5cbbb%2540ASEX01.ad.mmu.ac.uk%3Futm_medium%3Demail%26utm_source%3Dfooter>.
--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>

[casper] RE: Matlab Toolbox Requirements

[Neil Salmon]

In the longer term, move over to Python. N

From: 'Christman, Nicholas P' via casper@lists.berkeley.edu 

Sent: 08 January 2020 17:38
To: casper@lists.berkeley.edu
Subject: [casper] Matlab Toolbox Requirements

Good Morning CASPER Group,

My name is Nick Christman and I’m currently working through the SKARAB / CASPER 
toolflow integration process. Under normal circumstances, my organization has 
access to most of the Matlab toolboxes; however, it seems our project will need 
the DSP Toolbox license (not included by our org) which essentially means we 
will need to acquire standalone Matlab + Simulink licenses and all of the other 
toolboxes necessary to work with the SKARAB hardware. Herein lies our dilemma 
and the reason I’m reaching out to the group.

Ideally, to remain efficient and economical for the project, we would acquire 
only the necessary Matlab toolboxes that will allow us to execute the CASPER 
toolflow. Has anyone attempted this type of “minimal” installation for the 
CASPER toolflow? If so, do you have a list of required toolboxes? Or perhaps 
there is an alternative approach to solve our dilemma?

Thank you and I appreciate your support,

R/
Nick
__
Nicholas Christman
Electrical Engineer,
Systems Engineering / Testing & Evaluation,
Advanced Engineered Systems Group
Pacific Northwest National Laboratory

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/SA9PR09MB503902B9F5F69F372432ABB3F03E0%40SA9PR09MB5039.namprd09.prod.outlook.com.
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7b6ca0f6616b4aa0b48554a21af5cbbb%40ASEX01.ad.mmu.ac.uk.

RE: [casper] CASPER design question

[Neil Salmon]

Dear Gary and Neal,

I have similar requirements for non-radioastronomy passive mm-wave imaging 
applications, which may lie close to those of Lockheed Martin. I did find it 
difficult to adapt CASPER hardware as it has requirements not entirely aligned 
with these non-classic radioastronomy applications, ie it requires ~1 GHz 
bandwidth on hundreds of receiver channels. However, I watch this space in case 
capabilities start to emerge here where I could collaborate with community for 
spin out applications in pmmw imaging where powerful cross-correlators are 
required.

Many thanks,
Neil

From: Gary, Dale E. [mailto:dale.e.g...@njit.edu]
Sent: 24 December 2018 16:48
To: casper list
Cc: Neal Hurlburt
Subject: [casper] CASPER design question

Hi Casperites,

I received an inquiry from Neal Hurlburt, from Lockheed Martin (Palo Alto), who 
wants to look into the possibility of using CASPER hardware and tools to design 
a prototype system for interferometry of optical signals.  So far the 
specifications are quite fluid (see message below)--they would like a 500 MHz 
bandwidth, but would accept as low as 50 MHz.  However, he is looking for 
60-100 inputs, so I guess he is driven to the lower end of this bandwidth 
range.  Neal is not an engineer, but he can relay some suggestions from this 
list to engineering support at Lockheed.  If anyone has some suggestions for 
Neal, especially any projects of a similar nature, he would be delighted to 
hear from you.  I added his name to the cc list.

Many thanks,
Dale

Hi Dale,
Thanks for the info on your experience with CASPER. At a minimum, we are 
looking for a system that can digitize and correlate about 60 elements at 50 to 
500Mhz each. It sounds like CASPER is a good starting point. Who do you suggest 
we talk to at Berkeley?

Thanks,
Neal


Neal Hurlburt
Manager, Space Science & Software
Space Science & Instrumentation
Lockheed Martin ATC
650-354-5504
hurlb...@lmsal.com
--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to 
casper@lists.berkeley.edu.
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

RE: [casper] digital beamformer needed in Mexico

[Neil Salmon]

Hi Stan,

I needed hundreds of receiver channels beam-former, and with yours an order of 
magnitude higher, low front-end receiver channels costs are pretty key, plus 
the fact that the backend number crunch power needs to pretty large, a 
commercial solution might be the lowest cost option, dependent on budget 
timescales. There are a few commercial companies who could deliver this.

Neil

From: Stan Kurtz [mailto:kurtz.s...@gmail.com]
Sent: 25 November 2017 19:51
To: casper@lists.berkeley.edu
Subject: [casper] digital beamformer needed in Mexico

Hi to All,

I'm writing to ask if anyone knows of someone who might do ROACH-1
programming for a beamformer, as a 'consultant-for-hire'.

The Geophysics Institute at the National Autonomous University of
Mexico is currently using an analog Butler matrix to do the beam
forming on their 4096 element dipole array.  For more info, see:

http://www.mexart.unam.mx

or do an ADS search on MEXART and take your pick of articles.
The 2010 article by Mejia-Ambriz et al. in Solar Physics is a
good overview article.

A few years ago I bought a ROACH-1 and the 64 input ADC developed
by Rick Raffanti, with the idea that I might find a student to do
the beamformer as a project.  The student never materialized and
I don't have the time or the expertise to do it myself.

The MEXART team is anxious to get a digital beamformer going and they
have enough money to pay someone to do it.  They are not particularly
interested in it being a student project because that might take longer.
They want to get it up and running ASAP.

Of course they would like a flexible beamformer, with lots of
whiz-bang operating modes, but what they do now is form 16 beams along
the meridian, each at a different elevation, and use the array as a
transit telescope.  If they could just do that - but digitally, and
with good precision - it would be a big step forward.  Anything more
would be icing on the cake.  The design goal was to form 64 beams
along the meridian.

If anyone is interested in this and would like more details, let me
know.  I can answer most technical questions and for other details
(like money, timeframe, etc) I can put you in touch with the MEXART
staff.  Of course any other suggestions about how to proceed would
also be welcome.

Thanks, and regards from,
Stan Kurtz
--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to 
casper@lists.berkeley.edu.
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

[casper] Non-uniform FFT (NUFFT) as alternative to convolution gridding

[Neil Salmon]

Imaging fields of MRI, CT, radar are using algorithms referred to as 
non-uniform FFT, to make fast Fourier transforms (in 1,2 and 3 dimension) of 
data on non-regular sampling grids. This problem in radio astronomy was solved 
by using the technique of convolution gridding. With increasing numbers using 
and developing the NUFFT algorithms, might this be more effective technique 
than convolution gridding, for aperture synthesis imaging?

Groups developing NUFFT algorithms (so far I've identified are) at Berkeley, 
NYU, Michigan and Chemnitz, offer downloadable codes to run their algorithms, 
offering codes in a range of languages, including Matlab with mex functions for 
C programs. Might any known how good/easy these codes might be to implement, to 
do the equivalent of convolution gridding? Or perhaps might there be better 
algorithms from elsewhere?

Neil Salmon
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

[casper] PhD studentships in next generation micro/mm-wave technologies exploiting coherence theory using high-speed FPGA sampling & processing

[Neil Salmon]

Two studentship now available to develop novel technologies which exploit 
coherence theory using high-speed FPGA sampling and processing. These have 
separate applications but the main theme is using the crunch power of FPGAs 
linked to sensors to find novel algorithms to accumulate key quantities and 
metrics unobtainable my other means. Forward to those you think might be suited:

https://www.findaphd.com/search/projectdetails.aspx?PJID=69983
https://www.findaphd.com/search/projectdetails.aspx?PJID=72716

many thanks,
Neil
--
Dr Neil A. Salmon
Centre for Sensing and Imaging, School of Engineering, Manchester Metropolitan 
University, Manchester, UK
Office: +44 (0)161 247-1697

"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

[casper] PhD studentship - High-speed, short-word FPGA digital signal processing for next generation aperture synthesis imagers

[Neil Salmon]

There's a PhD studentship to work with me in the Imaging and Sensing group at 
Manchester Metropolitan University. The main drive of the work I'm interested 
in is the use of digital type radio receivers which sample short words (single 
bit, 1.5bit 2 bits) and then digitally cross-correlating them to develop 
sensing applications. The objectives are to examine simple analogue/digital 
electronic circuits, high-speed mathematical operations running inside FPGAs, 
and algorithms operating on accumulated quantities that exploit coherence 
properties of passive (radiometric) emission. Radio astronomy aperture 
synthesis is a good application of this technique, but the objective here is 
examine other moments of coherence and algorithms in a general sense to find 
new sensing  and imaging schemes, perhaps some quantum measurements, and to 
find new applications.

Interested parties should check out the link
http://www.findaphd.com/search/ProjectDetails.aspx?PJID=69983&LID=2719
http://www2.mmu.ac.uk/research/research-study/studentships/engineering-and-materials/
and contact me if they have an interest.

Although the PhD studentship is for a European student, I'd be interested to 
hear from potential students from further afield, for which I'd need to make a 
case and find a sponsor.

Many thanks,
Neil
--
Dr Neil A. Salmon
Sensing and Imaging Group, School of Engineering, Manchester Metropolitan 
University, Manchester, UK
Office: +44 (0)161 247-1697, Mob: +44 (0)7921172892

"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

Re: [casper] building 300-receiver channel cross-correlator

[Neil Salmon]

Dave,

Many thanks to you and others for help.

Perhaps I’d better start from scratch and design my own large n 
cross-correlator, with single bit samplers, looking to minimise risk.

Cheers,
Neil

From: casper-boun...@lists.berkeley.edu 
[mailto:casper-boun...@lists.berkeley.edu] On Behalf Of David Hawkins
Sent: 19 December 2015 19:46
To: casper@lists.berkeley.edu
Subject: Re: [casper] building 300-receiver channel cross-correlator

Hi Neil,

Here's my back-of-the-envelope calculations

1. Complex-valued multiplier (CMULT)

   a = a_re + j*a_im
   b = b_re + j*b_im
   c = a*conj(b) = (a_re + j*a_im)*(b_re - j*b_im)

   Given 1-bit sampled I+Q components, there are 4-inputs, so the logic will map
   nicely to a 4-input LUT. The number of LUTs required depends on the number 
of bits
   out of the product table.

   If the 1-bit values are assigned -1, 1, then each of the products takes on 
the
   values -1 or 1. The sums in the complex product each take on the values -2, 
0,
   or 2, i.e., three possible output values. Divide-by-2 and these three values
   can be -1, 0, 1, or the signed 2-bit codes 11, 00, 01, or you could add 1
   to get the products 0, 1, and 2, and use codes 00, 01, 10.

   Given the fact that each complex-valued product component has a 2-bit output,
   a complex-valued multiplier requires 4 x 4-LUTs.

   Your correlator needs 300x299/2 = 44850 of these CMULTs, i.e., 179400 4-LUTs.

   The 2-bit plus 2-bit output of these CMULTs would feed accumulators.

2. Accumulators

   If your 1-bit ADCs get stuck in one state, eg., always outputting -1 or 1,
   then you will get a static product out of your CMULT. For an integration time
   of 10ms at 300MHz, you have 3M samples, so your accumulator will have a bit
   growth of log2(3M) = 22-bits, i.e., each accumulator would need to have a
   worst-case bit-width of around 24-bits. For random noise the bit-growth
   would be half this. So your solution will depend on whether you expect to
   have to handle coherent signals, eg., RFI.

   The first thing to realize is that you do not need to use LUTs to implement
   these accumulators. You can use a combination of all the resources
   available to you on your selected FPGA. For example, you can use DSP blocks
   split into sub-accumulators, or you can use short counters implemented in
   LUTs, and then use RAM for long-term accumulators.

   For example, lets say you have an FPGA with a 48-bit DSP block, and you
   consider that 48-bit DSP block as 4 x 12-bit counters. If your CMAC outputs
   the unsigned codes 0, 1, 2, then the input to your DSP block accumulator for
   two complex-valued products would be;

   __00aa___00bb___00cc____000dd

   where the aa, bb, cc, dd are the 2-bit outputs of two CMACs.

   The unsigned 0, 1, 2 values can be accumulated for 2^12/2 = 2048 clocks
   before they overflow. (Overflow into the next 12-bit data word, and
   corrupt the DSP block 48bit accumulator contents).

   You could dump the DSP blocks every 2048 clocks into RAM, and then a
   long-term accumulator could read the RAM and accumulate the data further.

   The 44850 CMULTs could feed into 22425 of these 48-bit accumulators.
   Assuming a device with say 4000 DSP blocks, you'd need to implement
   the other accumulators in the fabric, eg., 18425 x 48-bits = 880k
   registers.

Clearly your dominant resource is going to be your accumulation logic, so you'll
want to carefully investigate methods of performing a low-bit-width accumulation
of the CMULT output, and then use RAM-based long-term accumulation, and then
get the data off the chip. What is the advantage of RAM accumulation? If the
fast accumulation occurs for say 1000 clocks, your RAM accumulation logic has
1000 clocks in which to do its work, so one accumulator can read two RAMs and
accumulate the two values for 1000 different partial products, i.e., you save
999 accumulators by reusing one.

This system sounds like it could fit into one FPGA. You'd have to figure out
how to get all 300 inputs onto the FPGA, eg., perhaps using 600 LVDS receivers
(assuming you could find a device with that many). The other option to consider
is several lower-cost FPGAs, eg., 4 x FPGAs with 150 LVDS pairs each linked
together with enough serdes links to take the data between the devices that
need it.

You should start by prototyping a simple design in HDL and testing it using
an existing development kit.

Cheers,
Dave
On 12/18/2015 8:23 AM, Neil Salmon wrote:
Thank you for your response. The system is part of a generic microwave/mm-wave 
aperture synthesis imaging system, so there’s an array of front-end heterodyne 
receivers with an IF earmarked at a centre frequency of 3 GHz (away from Wifi 
mobile comms), but the bandwidth is 300 MHz. Front-end initially may be 
receiving at a centre frequency of 20 GHz, but I could change this to 10 GHz or 
go up to 35 GHz. (I’ll be taking a single polarisation say horiz

Re: [casper] building 300-receiver channel cross-correlator

[Neil Salmon]

Rich, thanks to you and others for help, I'll probably post again when I've 
digested all comments and suggestions, best wishes, Neil

-Original Message-
From: casper-boun...@lists.berkeley.edu 
[mailto:casper-boun...@lists.berkeley.edu] On Behalf Of Rich Lacasse
Sent: 18 December 2015 20:04
To: casper@lists.berkeley.edu
Subject: Re: [casper] building 300-receiver channel cross-correlator

Hi Neal,

Some of this may be obvious to you, but I pass it along for what it's worth.


Please pardon my ASCII.  I'd like this to make it through people's spam filters!

As I'm sure you're aware, the general approach to correlating many antennas 
together tends to favor a triangular processing architecture as shown below.

  Grp 0  Grp 1  ...  Grp M  Grp N
|  |   | |
|  |   | |
  _  _   _  _ ___
Grp 0 - | C00 | -> | C01 | -> ...  ->  | COM | -> | C0N | --> |
 |_||_| |_||_| |
|  |   | |
  __|__  __|__   __|__ |
Grp 1 - | C00 | -> | C01 | -> ...  ->  | COM |--> |
 |_||_| |_| |
|  | |
......... | DATA
  __|__  __|__ | ACCUM
Grp M - | C00 | -> | C01 | --> |
 |_||_| |
  __|__ |
Grp N - | C00 | --> |
 |_| |

M = N-1 above, for notational simplicity

You certainly have too much processing to do in a single ROACH. You will have 
to divide and conquer somehow.  Grouping the samples from several antennas into 
groups and grouping of smaller correlators into a (at least
conceptually)
triangular array, as shown above would be one approach.

You will probably have to add delay stages for each antenna ahead of the 
correlators to align the wavefront.  You will also have to find a way to 
initially distribute the signals.
300 MHz is a little fast; you may have to back off to 150 MHz at least 
initially by parallelizing the data.

The CASPER way of passing signals around is to use a big Ethernet switch.  That 
would take care of all of your interconnects in the triangle above and also to 
the data accumulator to the right above.

As an alternative architecture you may want to have a look at powerMx.
See www.powermx.org

Rich

"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

Re: [casper] building 300-receiver channel cross-correlator

[Neil Salmon]

Jack,

I’m thinking the data rate and the computational load is just too large for 
Roach2, so it might be easier to design the whole think from scratch around 
latest most powerful FPGA, and designing single bit sampling receiver circuits. 
The IF centre frequency is likely to be ~3 GHz with the 300 MHz bandwidth, so 
I’ll need to design receiver analogue circuits that operate at these 
frequencies, with either analogue or digital downshift, which then interface to 
the FPGA board.

Would you happen to know which software packages I might use and have access to 
from ac.uk  if I wanted to design the digital receiver boards and FPGA boards 
at these frequencies?

Many thanks,
Neil

From: Jack Hickish [mailto:jackhick...@gmail.com]
Sent: 18 December 2015 17:26
To: Neil Salmon; James Smith
Cc: casper@lists.berkeley.edu
Subject: Re: [casper] building 300-receiver channel cross-correlator

I believe that each ZDOK is good for about 50 Gb/s. A ROACH2 has two ZDOK 
ports. Presumably you'll give up a pin or two for clocks so maybe 40Gb/s is a 
more realistic rate. We use an ADC that achieves 40Gb/s over 32 of the 40 ZDOK 
pin pairs. . But you'll also have to physically interface the digitizers, so 
whether you can have multiple digitizers time multiplexed on the same FPGA pins 
or whether you need one pin (pair?) per digitizer might also be limiting.

Jack

On Fri, 18 Dec 2015 at 16:46 Neil Salmon 
mailto:n.sal...@mmu.ac.uk>> wrote:
Jack,
Thanks for help. Do you have any idea of the I/O capacity of a single Roach2 
board – just trying to figure out how many I may need?
Thank you,
Neil

From: Jack Hickish [mailto:jackhick...@gmail.com<mailto:jackhick...@gmail.com>]
Sent: 18 December 2015 15:08
To: James Smith; Neil Salmon

Cc: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: Re: [casper] building 300-receiver channel cross-correlator

Hi Neil,

A bit more information would be useful, but it sounds like if you could 
construct a ZDOK card that interfaced some (40, one per differential pair?) of 
your digitizers to a ROACH board you could use a handful of ROACH boards to 
perform all of the cross multiplication and accumulation and interface with CPU 
data recorders / post-processors.

Jack

On Fri, 18 Dec 2015 at 14:26 James Smith 
mailto:jsm...@ska.ac.za>> wrote:
Hello Neil,

CASPER tools could probably do what you're looking for, but I found your 
description a bit confusing. You're going to need to clarify somewhat.

Regards,
James


On Fri, Dec 18, 2015 at 4:15 PM, Neil Salmon 
mailto:n.sal...@mmu.ac.uk>> wrote:
Anyone help?

I’m working in academia and need to build a 300-receiver channel single-bit 
digitiser / cross-correlator with a single frequency channel having a bandwidth 
of 300 MHz, centre frequency ~3 GHz. The single bit digitisers sample I&Q 
giving a total data rate of 180 Gbps and using XOR gates to do the 
cross-correlations, the total computation rate is 54 T XOR operations per 
second. I need to accumulate cross-correlations typically for times ranging 
from 10 ms to a few seconds. The system would comprise an array of single bit 
digitisers linked via a high speed data bus to FPGA boards for the 
cross-correlation/accumulation. I’ve no skills in board design but could 
probably learn VHDL. I don’t have funding to commission a design and build but 
wondered if anyone in this community could advise how I should go about 
building this system at our university.

Thank you for any help you can provide.

Neil
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

Re: [casper] building 300-receiver channel cross-correlator

[Neil Salmon]

Dan,

Thanks for your good points and others who have helped.

You’re indicating I should perhaps go for a new design (instead of using Roach 
– presumably due to high data + computation rate). So I’ll check out Simulink 
or HDL to see how many FPGA I’ll need.

However, I still need to sort the single bit samplers using the serial input, 
but could find Paul Horowitz’s write on this on the Casper site. Also if I’m 
going to have to design a board to fit all these 300 receiver channels on at 3 
GHz, with I&Q downshifters, interface to the FPGA, could you recommend any 
software that I should use to design these boards?

Thank you again for help.
Neil

From: dan.werthi...@gmail.com [mailto:dan.werthi...@gmail.com] On Behalf Of Dan 
Werthimer
Sent: 18 December 2015 17:31
To: Neil Salmon
Cc: James Smith; casper@lists.berkeley.edu
Subject: Re: [casper] building 300-receiver channel cross-correlator


hi neil,

as john pointed out, you can use the differential inputs of an FPGA
as a 1 bit ADC if you'd like.
there's a nice write up on this by paul horowitz and his students
who used xilinx fpga's as adc's.

if you want to use the fpga as the digiitzers,
you will need 600 LVDS inputs at 300 Msps, which means 600 pairs, or 1200 pins.
i think some of the larger fpga's will do this - you'll need to check.  (eg: a 
virtex ultrascale).
or you could split up the data over several chips (see below):

a larger problem is that you need 300^2/2 complex 1 bit multipliers and 
accumulators.
that probably will not fit on a single FPGA.   you might need to break this 
into four FPGA's.
i suggest you develop a complex multiplier accumulator in simulink or HDL,
and plunk down 300^2/2 of them, and compile them into a large ultrascale FGPA
and see if it will fit into 1 fgpa?  or  4?   or 9?   or 16?

best wishes,

dan


On Fri, Dec 18, 2015 at 8:23 AM, Neil Salmon 
mailto:n.sal...@mmu.ac.uk>> wrote:
Thank you for your response. The system is part of a generic microwave/mm-wave 
aperture synthesis imaging system, so there’s an array of front-end heterodyne 
receivers with an IF earmarked at a centre frequency of 3 GHz (away from Wifi 
mobile comms), but the bandwidth is 300 MHz. Front-end initially may be 
receiving at a centre frequency of 20 GHz, but I could change this to 10 GHz or 
go up to 35 GHz. (I’ll be taking a single polarisation say horizontal or 
right-hand circular – I’ve not decided yet)

Either way, I’ll need to digitise this 300 MHz bandwidth on each channel, and 
I’m quite happy with the loss in SNR in using a single bit digitisation, so 
satisfying the Nyquist criterion there will be I & Q channels, each generating 
a data stream at 300 M samples per second, ie a total of 600 Mbps for both I&Q 
per receiver channel, giving the total data rate of 180 Gbps. (sampling clock 
and mixing LO’s will be synched to a master oscillator)

(as for the 3 GHz centre frequency the I&Q digitisation could be bandpass 
sampling/digital down conversion or a second analogue downshift using a matched 
pair of mixers and then comparators in each section to generate I and Q digits)

So there will be this huge rate of I & Q data from 300 channels that needs to 
be cross-correlated in real-time with 95% duty cycle to avoid loss of SNR. 
(software correlation would generate just too much data for harddisk and a GPU 
PCIe bus solution couldn’t cope with the data rate – or at least I’d be 
uncomfortable about working close to data rate ceilings of PCIe.) That leaves 
the FPGA solution. So I need some high speed data bus to get the data into the 
FPGAs for cross-correlation. As I’m working single bits XOR gates will do 
nicely for the cross-multiplies and I want to store the four components of the 
cross-multiply in separate registers, just for diagnostic / trouble shooting. 
This gives the XOR op rate 54 T ops/sec and the requirement for the 180,000 
accumulation registers.

For me the challenges with be getting the arrays of single bit digitisers and 
linking them to the cross-correlators and doing the cross-correlation at this 
huge rate. Build of analogue front end heterodyne array and image formation 
algorithms I’ve done before. It’s just the digital hardware I need to sort. 
I’ve got a few researchers and postgrads around me in the engineering 
department who have general educational interests in FPGA technologies and the 
Xilinx and Altera University representative support under the university 
agreement. So I’m just wondering if I can do this with the Casper tools or 
others if necessary.

Hope this extra information help.  Many thanks for your help.
Neil

From: James Smith [mailto:jsm...@ska.ac.za<mailto:jsm...@ska.ac.za>]
Sent: 18 December 2015 14:25
To: Neil Salmon
Cc: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: Re: [casper] building 300-receiver channel cross-correlator

Hello Neil,

CASPER tools could probably do what you're lo

Re: [casper] building 300-receiver channel cross-correlator

[Neil Salmon]

Jack,
Thanks for help. Do you have any idea of the I/O capacity of a single Roach2 
board – just trying to figure out how many I may need?
Thank you,
Neil

From: Jack Hickish [mailto:jackhick...@gmail.com]
Sent: 18 December 2015 15:08
To: James Smith; Neil Salmon
Cc: casper@lists.berkeley.edu
Subject: Re: [casper] building 300-receiver channel cross-correlator

Hi Neil,

A bit more information would be useful, but it sounds like if you could 
construct a ZDOK card that interfaced some (40, one per differential pair?) of 
your digitizers to a ROACH board you could use a handful of ROACH boards to 
perform all of the cross multiplication and accumulation and interface with CPU 
data recorders / post-processors.

Jack

On Fri, 18 Dec 2015 at 14:26 James Smith 
mailto:jsm...@ska.ac.za>> wrote:
Hello Neil,

CASPER tools could probably do what you're looking for, but I found your 
description a bit confusing. You're going to need to clarify somewhat.

Regards,
James


On Fri, Dec 18, 2015 at 4:15 PM, Neil Salmon 
mailto:n.sal...@mmu.ac.uk>> wrote:
Anyone help?

I’m working in academia and need to build a 300-receiver channel single-bit 
digitiser / cross-correlator with a single frequency channel having a bandwidth 
of 300 MHz, centre frequency ~3 GHz. The single bit digitisers sample I&Q 
giving a total data rate of 180 Gbps and using XOR gates to do the 
cross-correlations, the total computation rate is 54 T XOR operations per 
second. I need to accumulate cross-correlations typically for times ranging 
from 10 ms to a few seconds. The system would comprise an array of single bit 
digitisers linked via a high speed data bus to FPGA boards for the 
cross-correlation/accumulation. I’ve no skills in board design but could 
probably learn VHDL. I don’t have funding to commission a design and build but 
wondered if anyone in this community could advise how I should go about 
building this system at our university.

Thank you for any help you can provide.

Neil
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

Re: [casper] building 300-receiver channel cross-correlator

[Neil Salmon]

John, yes sample rate is 300 Msps on both I & Q sections, ie total 600 Msps per 
channel, a massive rate when you've got 300 channels. As I understand if you 
put a comparator in front to the FPGA serial link it cleans up the 
digitisation. But no I don't yet have these. I need to get the basic building 
blocks right first then fill in the gaps. I'll check out the pico computing.
Thanks for help.
Neil

-Original Message-
From: John Ford [mailto:jf...@nrao.edu]
Sent: 18 December 2015 15:06
To: Neil Salmon
Cc: casper@lists.berkeley.edu
Subject: Re: [casper] building 300-receiver channel cross-correlator

> Anyone help?
>
> I'm working in academia and need to build a 300-receiver channel
> single-bit digitiser / cross-correlator with a single frequency
> channel having a bandwidth of 300 MHz, centre frequency ~3 GHz. The
> single bit digitisers sample I&Q giving a total data rate of 180 Gbps
> and using XOR gates to do the cross-correlations, the total
> computation rate is 54 T XOR operations per second. I need to
> accumulate cross-correlations typically for times ranging from 10 ms
> to a few seconds. The system would comprise an array of single bit
> digitisers linked via a high speed data bus to FPGA boards for the
> cross-correlation/accumulation. I've no skills in board design but
> could probably learn VHDL. I don't have funding to commission a design
> and build but wondered if anyone in this community could advise how I should 
> go about building this system at our university.

Hi Neal.  I think the main problem you face is the I/O.  I'm assuming your 
sample rate is 300 ms/s?  Clocking the FPGA at 300 MHz is pushing it, but not 
completely insane.  The 180 Gbps is above the capacity of the Roach-2, but 
maybe R-3 can do it.  There are other off the shelf hardware platforms you 
could look at, like pico computing that might have enough I/O.

Dumping the output at 10 ms shouldn't be a problem, as that's only 3.6 Mbps at 
a 4 bit width, or ~29 Mbps at 32 bits wide.

Do you already have the digitizers?  That's probably a nice bit of engineering 
in itself.  There has been some work on using the Xilinx I/O block bits as 
single-bit ADCs.  I don't remember the details.

John

>
> Thank you for any help you can provide.
>
> Neil
> "Before acting on this email or opening any attachments you should
> read the Manchester Metropolitan University email disclaimer available
> on its website http://www.mmu.ac.uk/emaildisclaimer "
>


"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

Re: [casper] building 300-receiver channel cross-correlator

[Neil Salmon]

Thank you for your response. The system is part of a generic microwave/mm-wave 
aperture synthesis imaging system, so there’s an array of front-end heterodyne 
receivers with an IF earmarked at a centre frequency of 3 GHz (away from Wifi 
mobile comms), but the bandwidth is 300 MHz. Front-end initially may be 
receiving at a centre frequency of 20 GHz, but I could change this to 10 GHz or 
go up to 35 GHz. (I’ll be taking a single polarisation say horizontal or 
right-hand circular – I’ve not decided yet)

Either way, I’ll need to digitise this 300 MHz bandwidth on each channel, and 
I’m quite happy with the loss in SNR in using a single bit digitisation, so 
satisfying the Nyquist criterion there will be I & Q channels, each generating 
a data stream at 300 M samples per second, ie a total of 600 Mbps for both I&Q 
per receiver channel, giving the total data rate of 180 Gbps. (sampling clock 
and mixing LO’s will be synched to a master oscillator)

(as for the 3 GHz centre frequency the I&Q digitisation could be bandpass 
sampling/digital down conversion or a second analogue downshift using a matched 
pair of mixers and then comparators in each section to generate I and Q digits)

So there will be this huge rate of I & Q data from 300 channels that needs to 
be cross-correlated in real-time with 95% duty cycle to avoid loss of SNR. 
(software correlation would generate just too much data for harddisk and a GPU 
PCIe bus solution couldn’t cope with the data rate – or at least I’d be 
uncomfortable about working close to data rate ceilings of PCIe.) That leaves 
the FPGA solution. So I need some high speed data bus to get the data into the 
FPGAs for cross-correlation. As I’m working single bits XOR gates will do 
nicely for the cross-multiplies and I want to store the four components of the 
cross-multiply in separate registers, just for diagnostic / trouble shooting. 
This gives the XOR op rate 54 T ops/sec and the requirement for the 180,000 
accumulation registers.

For me the challenges with be getting the arrays of single bit digitisers and 
linking them to the cross-correlators and doing the cross-correlation at this 
huge rate. Build of analogue front end heterodyne array and image formation 
algorithms I’ve done before. It’s just the digital hardware I need to sort. 
I’ve got a few researchers and postgrads around me in the engineering 
department who have general educational interests in FPGA technologies and the 
Xilinx and Altera University representative support under the university 
agreement. So I’m just wondering if I can do this with the Casper tools or 
others if necessary.

Hope this extra information help.  Many thanks for your help.
Neil

From: James Smith [mailto:jsm...@ska.ac.za]
Sent: 18 December 2015 14:25
To: Neil Salmon
Cc: casper@lists.berkeley.edu
Subject: Re: [casper] building 300-receiver channel cross-correlator

Hello Neil,

CASPER tools could probably do what you're looking for, but I found your 
description a bit confusing. You're going to need to clarify somewhat.

Regards,
James


On Fri, Dec 18, 2015 at 4:15 PM, Neil Salmon 
mailto:n.sal...@mmu.ac.uk>> wrote:
Anyone help?

I’m working in academia and need to build a 300-receiver channel single-bit 
digitiser / cross-correlator with a single frequency channel having a bandwidth 
of 300 MHz, centre frequency ~3 GHz. The single bit digitisers sample I&Q 
giving a total data rate of 180 Gbps and using XOR gates to do the 
cross-correlations, the total computation rate is 54 T XOR operations per 
second. I need to accumulate cross-correlations typically for times ranging 
from 10 ms to a few seconds. The system would comprise an array of single bit 
digitisers linked via a high speed data bus to FPGA boards for the 
cross-correlation/accumulation. I’ve no skills in board design but could 
probably learn VHDL. I don’t have funding to commission a design and build but 
wondered if anyone in this community could advise how I should go about 
building this system at our university.

Thank you for any help you can provide.

Neil
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "

[casper] building 300-receiver channel cross-correlator

[Neil Salmon]

Anyone help?

I'm working in academia and need to build a 300-receiver channel single-bit 
digitiser / cross-correlator with a single frequency channel having a bandwidth 
of 300 MHz, centre frequency ~3 GHz. The single bit digitisers sample I&Q 
giving a total data rate of 180 Gbps and using XOR gates to do the 
cross-correlations, the total computation rate is 54 T XOR operations per 
second. I need to accumulate cross-correlations typically for times ranging 
from 10 ms to a few seconds. The system would comprise an array of single bit 
digitisers linked via a high speed data bus to FPGA boards for the 
cross-correlation/accumulation. I've no skills in board design but could 
probably learn VHDL. I don't have funding to commission a design and build but 
wondered if anyone in this community could advise how I should go about 
building this system at our university.

Thank you for any help you can provide.

Neil
"Before acting on this email or opening any attachments you should read the 
Manchester Metropolitan University email disclaimer available on its website 
http://www.mmu.ac.uk/emaildisclaimer "