A post from Steve at Flex
- 303 Likes
Once we realized it was possible to build a direct sampling radio, all the "what if..." conversations started. What could we do if we did this? What would someone do with that? Would it be better if we did this or that? At the time, PowerSDR was the de facto standard in SDR, but we were keenly aware of the limitations of the architecture. Namely that it would not work well in the IoT (Internet of Things) age, remote would be a kludge, the more data we wanted to process the more powerful computer you would have to buy, etc. It's just not scalable. At the time, the HPSDR team had built a working direct sampling receiver and we looked over their architecture and considered it. It also had the critical flaw of having to have a fat communications pipe to the computer. We decided putting the processor in the radio was the way to go.
We contacted Intel, Freescale, Texas Instruments, Xilinx and Altera and had meetings with each to discuss what technologies we could use to build the compute engine in the radio. We briefly discussed doing everything in an FPGA, but this was quickly ruled out because it takes roughly 10x to build the same thing in an FPGA as you can build in a processor. Our Avnet/Xilinx FAE at the time put it very matter-of-factly when she said something like: "FPGAs are hard. You wouldn't use them if you had any other way of doing it." But to do direct sampling, an FPGA was required. At this point we knew that we were going to be marrying an FPGA and a processor. All the while that we are making these decisions about the hardware, I'm thinking about how the software will work and building the architecture for that in my head.
FPGAs can have what are called "soft processors" which are processors that are actually built in the fabric of the FPGA. We have used these before and they can be handy, but there is a key problem: all of them are limited to about 100-150MHz of clock speed. We knew that this wouldn't cut it. Several of the FPGAs have what are called "hard processors" which are processors that are part of the silicon and they run at native speeds, in the 750-1500MHz range. Xilinx previously had used PowerPC, but now was promoting a new family called Zynq which included an ARM processor. The world has largely abandoned PowerPC and MIPS and settled on ARM for embedded licensed processors. We liked the ARM architecture and the toolset and toolchain were rich -- we were sure that ARM would be around for a while. But Zynq was expensive and and brand new.
We talked with Intel who had a line of embedded processors and we liked those OK, but there seemed to be a lot of interface work required with them. We moved to talking with Freescale and TI because each had DSP processors which we felt would give us a lot more power since we were going to be doing DSP. TI was a full generation ahead of Freescale at the time so we got serious about TI. TI had better raw compute power and we really liked where they were going so we picked TI. We also had a good relationship with TI and felt like that would help us. All the while that Gerald and I were visiting with these companies, we would walk out of the meetings and talk about what we could do for ham radio with each solution.
We ended up picking Xilinx and TI for the computing parts. At this point, I had a pretty good idea what the software architecture was going to look like and so Eric and I started talking about the software architecture in detail. Our codename for the radio was MICROBURST and SmartSDR's codename was SMOOTHLAKE. Eventually, SMOOTHLAKE got the name SmartSDR and I think it was from Klaus, DK7XL, our EU representative.
The path we picked was filled with peril and we received advice that we could easily kill the company with the decision we had made. We knew that if we could do this, we would advance the technology in ham radio in one huge leap. Gerald asked the team if we were committed to making this radio happen. This is one of those moments where someone looks you in the eye and you know that this is a real commitment --