Isn't any "Application-specific integrated circuit" out there to run Seti?

There is so much volunteers, that maybe a lot of people would be interested in buying such special purpose hardware. Say on a special dedicated pci slot board?

---

Isn't any "Application-specific integrated circuit" out there to run Seti?

There is so much volunteers, that maybe a lot of people would be interested in buying such special purpose hardware. Say on a special dedicated pci slot board?

One more time.
The whole point of seti@home is that seti does not have money for specialized hardware.

---

One more time.
The whole point of seti@home is that seti does not have money for specialized hardware

I meant some private business building the hardware for the volunteers to buy.
Nothing to do with the seti budget!

---

One more time.
The whole point of seti@home is that seti does not have money for specialized hardware

I meant some private business building the hardware for the volunteers to buy.
Nothing to do with the seti budget!

I know what you mean. It might be possible to accomplish today. So. "Go forth and DO IT!"

Keep us up to date please and good luck.

---

One more time.
The whole point of seti@home is that seti does not have money for specialized hardware

I meant some private business building the hardware for the volunteers to buy.
Nothing to do with the seti budget!

The market for a specialized, niche SETI ASIC would not be lucrative enough to pay for the research and development, drivers, support and ongoing maintenance.

Better to have a more generalized ASIC that more than just one tiny market can use. An ASIC that can be used for specialized math operations, is highly paralleled, and can be used by anyone willing to write the software for it is a far larger market than just one single project.

We already have such an ASIC: GPGPUs.

I guess you are thinking of the specialised Bitcoin mining GPUs you can buy?

Yes technically it would be possible to design one of those to do SETI work, but it would cost $$. Because there is a gold rush on Bitcoins recently, people are willing to throw money at them, in the hope of actually getting a return. It might also be said that in a gold rush, the surest way of getting rich is to sell picks and shovels. That's what these guys are doing. They can make more $$$ selling the hardware than that could keeping it and running it themselves. But that's a different subject.

SETI credits are still worth a much smaller amount, in fact I've not heard of anyone even getting a the mythical free toaster. ;-) So you simply are't going to find a mass market for this gadget.

Last problem, and probably the biggest. If you did sell a heap of these units, and then SETI changed the format of the search, (which they do occasionally) the hardware is then useless, it's hardware coded to the current format. But guys running on "general purpose" auxiliary processors (GPUs) are either natively supported by a new standard app, or simply need to tweak their custom software to suit the new format.

Ian

It would be pretty trivial (for someone that understands FFTs and an HDL) to make an FPGA binary that just does the FFTs which I understand are the bulk of the SETI algorithm. One could then write an OpenCL driver that would chirp the data on the CPU and send the FFT work to the FPGA. I can write the HDL but the math and driver programming are above me

This all applies for ASICs as well, but actually producing the chips costs a lot of money. Fortunately the FFT algorithm will likely never change enough to require a new chip if you put some forethought into it. High-level changes could be made at the driver level.

---

It would be pretty trivial (for someone that understands FFTs and an HDL) to make an FPGA binary that just does the FFTs which I understand are the bulk of the SETI algorithm. One could then write an OpenCL driver that would chirp the data on the CPU and send the FFT work to the FPGA. I can write the HDL but the math and driver programming are above me

For FPGAs that's all library stuff in Verilog or whatever, you just need to provide the glue. Unfortunatly S@H is not all FFTs, there are some other fancy transcendental/complex functions as well, but I'm sure the FPGA makers have them all in libraries too. In the end it's all the other libraries[1] that S@H links to that will kill you, you have to programme them too.

This all applies for ASICs as well, but actually producing the chips costs a lot of money. Fortunately the FFT algorithm will likely never change enough to require a new chip if you put some forethought into it. High-level changes could be made at the driver level.

[1] e.g.

[eesridr:BOINC] > ldd projects/setiathome.berkeley.edu/setiathome_x41_x86_64-pc-linux-gnu_cuda55
	linux-vdso.so.1 =>  (0x00007fff90bfd000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003c62200000)
	libcudart.so.5.5 => /usr/local/cuda-5.5/lib64/libcudart.so.5.5 (0x00002aeb02341000)
	libcufft.so.5.5 => /usr/local/cuda-5.5/lib64/libcufft.so.5.5 (0x00002aeb0258f000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003c63e00000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003c61600000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003c63a00000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003c61200000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003c60e00000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003c61a00000)
	librt.so.1 => /lib64/librt.so.1 (0x0000003c62600000)

---

It would be pretty trivial (for someone that understands FFTs and an HDL) to make an FPGA binary that just does the FFTs which I understand are the bulk of the SETI algorithm. One could then write an OpenCL driver that would chirp the data on the CPU and send the FFT work to the FPGA. I can write the HDL but the math and driver programming are above me
...

I suspect that's an impractical idea. Although FFTs are important for S@H, they only use very roughly 30% of the run time of a CPU task. IOW, an FPGA doing only the FFTs could improve run time by 30% at best. A relatively inexpensive GPU running existing CUDA or OpenCL applications would be faster, though the FPGA solution might require less power.

                                                                   Joe

Also take account for data transfers time to and from device.
Data transfer time can be real killer of co-processor approach. That was for Brook+ AP for example where data needed to be returned to host for FFT with all other transformations on GPU. Such approach turned out to be slower than to implement only FFA on GPU leaving data that requires FFT on CPU only.
Cause FFT only part (big part but only a part still) we will need to transfer whole data array back and forth betweenn coprocessor and system memory (over PCI-E link in best case, most probably via PCI).

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.