DSP Inside TI Radar Puts AI on Edge
eetimes.com
eetimes.com
Granted, good machine learning is not all about compute power, and you can certainly do interesting things with less power. But this is not bleeding edge deep learning for sure :)
On the other hand, TI is a company you can actually count on to work with you to be able to build a product that can be verified to be dependable, in a mission-critical, hard real time sense. TI open sources most of the software stack.
NVIDIA, well, not so much. I've run into serious issues with their binary blob drivers and their engineers have a rather DGAF attitude about the whole thing. Secrecy and bluster are the name of the game. Torvalds' opinion on the matter rings true.
TI just seems friendlier and less cutthroat. Their support of the BeagleBoard etc is telling.
There's a lot of work between reflecting radio signals and having a "radar image" that can be fed to AI systems, and that seems to be the main target of the dsp.
I too have nothing but great things to say about TI.
By the time you have a reasonable dataset, you've also had a reasonable amount of training... of course, with only a little training on the complete dataset.
There is nothing more irritating than to finalize a design for manufacturing and being hit with an EOL'd part with some ridiculously short deadline.
You end up with having to choose between to really bad choices: stock up as many parts as you can risking ending up with unused inventory (and still a fair chance of running out on the other end) and redesigning the product.
Their SoCs are ridden with HW bugs and TI will not put every HW bug to errata - e.g. their infrastructure pktdma will hang if you will use chained descriptors but you will not find it in silicon errata. TI response was - "just don't use it" and refused to verify it on their side.
The ISA of c66x DSP is just stupid - you have quad SP multiply but only double SP addition - forming registers back and forth in quads will result in MV instructions often (because compiler is not so smart). There are no real vector registers, "vector" instructions take 4 or 2 32bit registers.
Want to compute power of individual complex int16 in a vector ? You are out of luck - DDOTP4H will add everything together.
There is even no way to utilize their multipliers fully since load&store is 2x64 bit, while multiplier can perform 8 SP multiplies per cycle.
Moreover memory access to L2 is so slow that you will wait in memory stalls (there is no HW prefetch from L2 to L1D cache) and L1 SRAM is way to small to do anything serious (32 kB).
After trying other DSPs, like CevaXC or VSPA, TI looks like poor joke. Their C7000 that supposed to address some of those problems is long overdue and will be well underpowered comparing to recent Ceva DSPs or NXP VSPA.
Typically, the dsp or fpga is used to handle the time critical pieces, i.e. generating RF, and the pc is there to command and collect data.
There are a variety of vendors you can choose from for this type of setup. From SoC to PCIe fpga for a server, all depends on your applicatio.
The application to the automotive sector might be novel.
The baseband bandwidth for FMCW RADAR is not that much, so they are able to pull this off with a DSP. It’s the RF integration that impressed me. I’m presently using some ADI SiGe mmWave ICs (impressive themselves), and those are close to $300 for the TX/RX pair, and that’s only the RF to analog baseband. The TI part is $55 for a fully integrated chip. Just need a PCB/antenna and supply regulators.
Short white paper here:
I'm curious what kind of Rx sensitivity they can get for the HF range.
They may be new buzzwords, but it's important to differentiate them so that the use cases and end users they are targeting become more narrow and specific.
The chip in question only emits 20 mW, and coupled into a 10 dB gain antenna, the EIRP is still only a few 100 mW. Now spread that over a few 1000 cm^2, and it’s not much at all.
For a fun experiment, put your phone in a microwave. Notice the WiFi bars go to zero, but the cellular bars don’t change (much).
And neither will you.