Steve Hicks on 8-Slices and User Defined Waveform Functionality in the 8XXX

Russ Ravella

I've had some exchanges with Steve Hicks on the Flex groups.io reflector about the possibility of an 8-slice version of the 8XXX and on its restoration of User Defined Waveform functionality. His responses were both informative and encouraging so I thought I'd share them here:

"KR6W: We will undoubtedly be increasing the number of available slice receivers over time. I do not see a world where we're not doing that.

On the waveform functionality, we have continued to enhance this capability in SmartSDR. As you may know, we designed the SmartSDR Waveform API to allow waveforms to execute from both outside as well as inside the radio. We have limited capability from a processor standpoint to run inside the FLEX-6000, but we've done a lot to enhance this in the FLEX-8000. But external has always worked well and just to illustrate that, go have a look at the new ezDV product that is over at TAPR. This device can be turned on and configured and when placed on the local network as your FLEX-XXXX, two new modes show up in your radio that support FreeDV upper/lower sideband modes. It's incredibly simple to use this device and all the processing is done externally. Because of our architecture choice of requiring the waveform to interface with the radio, this box can be on the network where your radio is, you can open up an iPad in the field (anywhere), run SmartSDR for iOS and use FreeDV. It's a brilliant example of how to do the waveform API correctly. Both SmartSDR for iOS and ezDV are developed by third parties with very little help from FlexRadio and operate as if they were designed along-side the radio.

Steve"

(note: Bret WX7Y replied to this post saying he actually has the ezDV and that it's easy to use and works extremely well. I've heard other similar reports on it. Sounds pretty cool.)

I'd previously asked Steve about 8-slices specifically with respect to the 8XXX's present processing power and this was his quite detailed response:

"KR6W: Your understanding is basically correct. We are not yet certain the total number of slices that we can support in the 8000 series radios. Most people that use computers have a basic familiarity with how computer software is developed and run: someone writes programs, those programs require a certain amount of CPU power, IO bandwidth, memory bandwidth and space per unit time. The faster your processor and the more you can do in a single instruction, the more you can do. FPGAs are very different...

The construct in the FPGA that we map into is called the "fabric." The fabric of different FPGAs has different characteristics apart from the basic resources quoted by a manufacturer. These characteristics affect how much of different kinds of things can be used in the FPGA (routing and clocking resources, for example). In an FPGA, a "program" is generally multiple strings or a complex web of computing resources that are all pieced together and clocked. It's a little like having a few hundred processors, but each processor can only do a small number of things. The techniques for "doing more" in an FPGA can be complex. For example, if you have a multiplier and you need to use it once out of every 16 clock cycles to perform some calculation, to get more "power" out of the FPGA, you can multiplex the multiplier making it do something on one clock cycle and then something different on the next clock cycle by changing its inputs and outputs each clock cycle. Doing this takes more fabric, but may reduce the number of multipliers your design requires (giving you more left over for something else). If you multiplex, you have to keep track of what that multiplier is doing at any instant. With your design, instead of running at a fixed clock speed you can ratchet-up the clock speed until the part cannot "meet timing." As a practical matter, we generally pick a frequency we want to operate at and then make things work at that clock frequency because ratcheting-up the speed breaks a lot of things with no certainty you can get to the higher speed by working the problem.

Not meeting timing means that one or more operations you are doing in the FPGA cannot complete in a single clock cycle. If you still want to run faster, you can pipeline the operations (side note -- if you look up modern processors you will see that they all do pipelining internally, but you just don't know about it as a conventional programmer, generally). To pipeline, you split an operation into multiple pieces and make one piece happen this clock cycle and then the other part happen the next clock cycle. This uses more resources in the FPGA, but you may end up better off if you can raise the clock frequency and do more operations in a given unit of time. Then you can crank up the speed again. The FPGA has what the manufacturer considers the fastest you'll be able to clock if things are perfect (called the Fmax), but we (and most others) don't get to that speed. Having said that, our new part has a 20% faster Fmax compared to the 64/6600 part. As complex as all this sounds, it's not this simple...

I say all of these things to explain that what we wanted to do first was move our existing 2 and 4-receiver designs into the new FPGA and make those work. Both of these designs were "modernized" with the 64/6600 and we did not go through this process with the 6700 design. In the FPGA, we will be experimenting with a number of new things including the announced spectrum overview display and looking at how efficiently we can do new things and what kind of "space" we have left. Additional receivers is something we are discussing and we'll likely be looking at in the coming year. After we see what we can accomplish with what we have, we may decide to jump in and add more receivers or we may decide we have something more valuable to the amateur community that we want to do first.

This is potentially not a very satisfying answer. We are aware that the 6700 is an aging design, is no longer available and that there is demand for more receivers so we haven't lost sight of that."

Hope that's helpful,

73 Russ KR6W