What is best options for simple but very low latency calculations?

Question

After reviewing my math, it turns out I had made a mistake in my calculations and was off by a couple factors. In an effort to make this question worthwhile, I am still interested in what type of device can perform very specific calculations at at high seeds and low latencies.

Answer 1

Sounds interesting.
1 / 10ns = 100MHz. Pretty quick... Depending on what exactly "a few low latency calculations" entails, this may be a job for an FPGA (or an ASIC..)

Most modern FPGAs have max clock speeds in excess of 300MHz and come with things like with dedicated DSP blocks to make life easier. You can parallel (and pipeline if possible - probably not in this situation I guess) as necessary to achieve as fast a speed as possible. To figure out whether you can meet the timing or not, you could download one of the vendors (e.g. Xilinx, Altera, etc) IDEs, write your HDL and run a simulation.

You may need to look into some analogue trickery in combination with the FPGA, or attempt to start measurement earlier than impact (if possible) to give yourself more time.
More information about exactly what you are trying to do would probably help with the details (e.g. how exactly do you intend to affect the impact?)

EDIT - to answer the edited question, an FPGA (Field Programmable Gate Aray) is exactly the thing you are looking for if you want custom/specific calculations at high speeds.
Google (and here) has tons of info on them so I won't go into too much detail, but basically they are a large array of logic gates that you can connect up in any way you choose, effectively designing your own custom digital IC.
For example if you want a really fast FFT, you could literally devote the entire chip to optimising just for that one function. You can implement adders, counters, RAM controllers, SPI, UART, "soft core" processors, etc, etc, basically anything you want.
They are usually reprogrammable as many times as you want (depending on the technology used to hold the configuration - you can get RAM based, Flash based, antifuse, etc - most are RAM based) and have onboard RAM to use with your design.
I would suggest reading up a bit about them (The Design Warriors Guide to FPGAs is a pretty good book IIRC) and then grabbing a book on HDL, downloading an IDE and trying some stuff out in simulation. Then grab a starter board from Digilent (e.g. something like the Nexsys2) and away you go.
FWIW, Xilinx and Altera are the two big players in the market, so it's probably best to start with one of them. The Spartan series from Xilinx are popular and versatile FPGAs.

When you are ready to design your own boards, you will need a download cable to configure the FPGA via JTAG - these can be purchased from Xilinx/Altera or you can get much cheaper version on eBay that do the same.

Answer 2

I think that your requirements are unreasonable and unnecessary. Let's go through some quick calculations to check this out.

One of the quickest, commonly available bullet is the .223 Remington, which travels about 3,000 feet/second. In 10 ns, that bullet will have traveled 0.00036 inches.

Now, your question was about low-latency calculations and not about actually sensing the speed of the impact. So I am going to ignore the whole sensing problem and assume that you already know a way to sense the impact accurately and quickly enough.

With a commonly available, inexpensive FPGA running at 100 MHz I estimate that you can do the calculations in about 10 clock cycles. 10 ns per clock. This is just a guess since you didn't say exactly what the calculations are! Even so, this is 10x longer than your 10 ns requirement. However, in those 100 ns the bullet has only traveled 0.036 inches!

So, even if your 10 ns requirement is real, it can be compensated for simply by moving your sensor 0.036 inches farther out!

I chose the .223 bullet as an arbitrary example. There are faster bullets but not significantly faster. There are some rounds that go about 4,000 feet/second, for example. The faster speed of these does not change the basic conclusions.

I dare say that if you are working on a personal project with projectiles that are not bullets but going faster than 4,000 feet/second then you might want re-evaluate your life choices. If your projectiles are going slower than that, then your 10 ns requirement is not realistic and a simple mechanical rearrangement of things could solve the problem.

Answer 3

Your requirements are very difficult to meet, and this will probably only be possible in a restricted set of circumstances.

For example, if you want to detect bullets hitting the side of a battleship, and respond within 10ns, this is probably impossible. But if your target is an inch wide, and the projectile is easy to detect, then this is easier, but still not trivial.

Without knowing a bit more about your application, our suggestions are going to be shots in the dark. Firstly, I would forget about microcontrollers or FPGAs. You're going to need a really fast one. I think that an analogue solution will be easier to implement.

If your target is small, and the projectile isn't too small, then you may be able to detect it with a pair of lasers and fast photodiodes. When the projectile interrupts the first laser, a capacitor is rapidly charged with a constant current driver. When the second laser is interrupted, the charging is halted. The lower the resulting voltage on the capacitor, the faster the projectile was traveling. The good this about this solution is that you can position the lasers far apart, and far from the target. This way you can know the speed before the impact. For all of the electronics, you're going to need to choose your parts carefully. Many parts simply won't be fast enough. You'll also need to use small surface mount parts. As Olin mentioned, 10ns is only enough time for an electric signal to travel a few feet, so no long wires.

Answer 4

The latency problem may not be in the speed of the computation (you might be able to do a couple low precision multiply-accumulates or maybe one divide on a 1 GHz microcontroller or a 250 MHz FPGA in 10 nS), but in getting any signals on and off of the microcontroller or FPGA chip doing the computation. The rise time of the input and output signals and the IO pad/port delays on the chip would likely eat more than 10 nS before you could even start your computation or could inform anything outside of the CPU chip of any computation results.

Added: If you actually have more like 1 uS, then many multi-100MHz microcontrollers with direct GPIO could probably clock in some input, do a few dozen arithmetic instructions and register an output, as long as the code doing so was dedicated and not dependent on a slow OS/SW interrupt handler.